05:45 <SiFuh_> farkuhar: I see your concern but 'users' in '/etc/groups' is a system group. It should remain untouched. Yes, you are much better off using login.defs and setting 'USERGROUPS_ENAB yes' also set 'UID_MIN 1000'. If you set only 'UID_MIN 1000' all users new will have the GID 1000 but the UID will go up incrementally. If you also set 'USERGROUPS_ENAB yes' all users will begin with a UID of 1000 and a

05:45 <SiFuh_> corresponding GID will be created also going up incrementally. To overide this, so for example, port builders creating users or groups these can be overridden by using various flags like -g and -U. If -r is used then the account will have a double digit GID and a double digit UID. Unfortunately if you are creating a daemon account without -r the user will have a UID of 4 digits unless you specify -u

05:45 <SiFuh_> and manually create your own UID. If you do manually set with 3 digits and did not specify -N or -g a group will also be created with same 3 digits as the manually set UID. The issue with manually setting UIDs is that it may error out if another UID already exists with the same digits. SYS_UID_MIN could theoretically be changed to 100 if you wanted to enable 3 digits instead of 2.

13:09 <farkuhar> SiFuh: thanks for the detailed analysis. I'm curious to get in touch with the admins of the OpenBSD system that has duplicate entries in /etc/group, and thereby learn whether it causes any problems (on OpenBSD at least) to have non-unique resolution of group name to gid.

13:10 <SiFuh_> NetBSD does as well

13:11 <SiFuh_> I think the duplicate entries are a missconfiguartion to be honest

13:12 <SiFuh_> I went through all the /etc/group files i have backed up from 3.x days until 7.2 (Beta) and not a single one has users mentioned twice.

13:13 <farkuhar> because as you say it might break things to change the existing line in our /etc/group, but *adding* a new line might be less dangerous (although /usr/sbin/grpck will probably issue a warning)

13:13 <SiFuh_> https://github.com/openbsd/src/blob/master/etc/group

13:16 <SiFuh> Yeah but users are no longer being added to the group 'users'. These days most distributions are creating a group which is the same name as the users name

13:17 <SiFuh> I still use the original from my Solaris days, was adm but is not admin. Every new system is sifuh:admin

13:17 <SiFuh> not/now*

13:18 <SiFuh> Also using the original gid/uid from those days and they are 3 digits not 4.

13:19 <farkuhar> so most distributions have defaulted to "USERGROUPS_ENAB yes" in login.defs, or are they providing a wrapper script around useradd?

13:20 <SiFuh> 4 digits has basically become the conventional way now. Probably because too many services as opposed to those days and the interference and inconvenience of now being able to use the same UID/GID accross different machines

13:22 <farkuhar> anyway, our shadow port has just had its version bumped, with no changes to login.defs. We can put this discussion on hold until the next upstream release (hopefully with beerman's pull request merged).

13:22 <SiFuh> I am sure this is why stenur brought it up. Yes many of the distros are.

13:26 <farkuhar> I'm pretty sure stenur would disapprove of taking anything from a distribution that uses systemd. :-P

13:27 <SiFuh> I would too

13:46 <SiFuh> farkuhar: I just checked these and all have it enabled Void Linux, Ubuntu, Arch linux, Slackware and Debian

13:53 <SiFuh> farkuhar: Apart from alpine linux they all seem to just follow the defaults that the shadow package has https://github.com/shadow-maint/shadow/blob/master/etc/login.defs

14:28 <farkuhar> SiFuh: it looks like our port has been shipping the same login.defs since CRUX 3.5, if i'm reading the right git history ... https://crux.nu/gitweb/?p=ports/core.git;a=history;f=shadow/login.defs

14:36 <farkuhar> the April 2006 commit is pretty interesting ... that's when USERGROUPS_ENAB got changed from "yes" to "no", alongside some other patches to useradd.c

14:37 <SiFuh> 2019-02-03

14:38 <SiFuh> When PAM was introduced in

14:38 <SiFuh> 2012-07-14 When SYS_UID* was changed

14:40 <SiFuh> Oooh, Yeah I see that. 'shadow: allow to create per-user group when supplying the -n switch'

14:42 <farkuhar> 2012-07-14 I guess you could call it a "change" to create settings that weren't previously there. No mention of SYS_UID or SYS_GID in any previous blobs.

14:44 <SiFuh> So 16 and 1/3 years ago jw decided to change logind.defs defaults. I wonder why.

14:45 <farkuhar> the flyspray task that led to the 2012-07-14 commit has this gem: "For any existing installation it would be a mess to use upstream's config (at least for UID/GID distribution): our defaults differ significantly. Note, that this is mostly cosmetic ugliness."

14:50 <farkuhar> "our defaults differ significantly" is easily remedied by changing our defaults for *new* installations, and then we could use upstream's config as-is. Existing installations won't be affected if they have an appropriate directive in pkgadd.conf (UPGRADE ^etc/.*$ NO)

14:51 <SiFuh> Feb 29 2012 jue> maybe it would be better to use the default login.defs that comes with shadow instead of our own?

14:51 <SiFuh> Heh

18:52 <beerman> the update to the manfile has been merged, so expect to see 1000 being used. I don't really see why we should set 100 over 1000, either. i agree with it not affecting old installs for attending users, and i don't care if its 1000 for a new one

20:05 <jaeger> I don't have a preference, only noticed it when it changed :)

20:20 <SiFuh> Every distro I have looked at keeps 100:users in /etc/group, but they also are using the default login.defs file from shadow.

21:11 <ivandi> USERGROUPS with umask 002 makes sense for multi user systems (sharing files with 'friends' only). On a single user setup the gid is irrelevant but defaulting to 1000 will be somewhat confusing for usergroups setup (uid=1000:gid=1001, 1001:1002 etc...), so keeping the legacy 'users' gid 100 makes more sense.

21:14 <ivandi> i switched to usergroups because i wanted to easily use my host user inside docker or lxc and virtually everywhere the first created user is 1000:1000 usergroup

21:16 <SiFuh> users:100 is the same for all distros and should stay that way

21:17 <SiFuh> A new concept was later added with user foo and group foo both having 1000:1000 and the user bar with group bar having 1001:1001

21:20 <SiFuh> The group 'users' has nothing to do with the user:group 1000:1000

21:24 <ivandi> yep, foo can put bar in its group and give him access to 660 files, but foobar can't access foo nor bar files. if by default all are in users that doesn't work and needs a new group for foo and bar only.

21:26 <SiFuh> usr which became user was actually a very old concept long before shadow even existed

21:28 <SiFuh> Unix and Linux still has a lot of old parts hanging around. Mostly due to compatibility. If I remember correctly FreeBSD doesn't have the users portion anymore. I will need to verify that though

21:31 <SiFuh> I vote to keep it, but if it is to be deleted entirely then I am not against it. But you can't change it the GID to 1000 in /etc/group because as ivandi says when you add a new user the UID will be 1000 and the GID will become 1001 instead of 1000 as it is owned by 'users' now

21:31 <SiFuh> ivandi: that made sense?

21:33 <ivandi> as i said having users::1000 doesn't make sense to me

21:34 <SiFuh> Yeah, it's entirely stupid. Setting the UID_MIN option in login.defs to 1000 makes more sense

22:11 <ivandi> looking at man login.defs, the behaviour of USERGROUPS_ENAB depends on having *the same* uid:gid and *the same* username:groupname. yet another argument against users::1000

22:23 <farkuhar> ivandi: I agree, it makes more sense to follow the upstream config that comes with shadow, and leave /etc/group as it is. Trying to work around a custom login.defs that we inherited from the days of CRUX 2.5 is not worth the trouble.

22:28 <farkuhar> although it might be worth a mention in the Handbook, for anyone who hasn't performed a fresh install since more than two years ago (and would have expected useradd without the -g flag to automatically set 'users' as the primary group).

23:15 <farkuhar> s/Handbook/Faq/; the Sandbox version of the handbook is already rather verbose, so the FAQ is a better place to clear up these minor differences in behaviour between CRUX 3.7 and earlier releases.