3

In order to successfully implement w/r access via ACL for external storage with ext4 fs I need to assign default group id for files on storage.

LSB_5.0.0 say:

This specification makes no attempt to numerically assign user or group
identity numbers, with the exception that both the User ID and Group ID
for the user root shall be equal to 0.

Shame for Linux vendors!

Are there any convention about group ids among major Linux distros?

In Debian policy I found that default group values defined by base-passwd package in /usr/share/base-passwd/group.master file. Among them this groups look good candidate for ACL defaults:

tape:*:26:
backup:*:34:
operator:*:37:
plugdev:*:46:
staff:*:50:
users:*:100:
nogroup:*:65534:

Never works with Suse/RH/Slackware distros policy documents... Also interesting if FreeBSD/OpenBSD/MacOS share convention with Linux distros.

UPDATE I compare MacOS X (dscacheutil -q group) with Debian and only few group ids are matched:

sys:*:3:

UPDATE 2 I compare FreeBSD and Debian /etc/group file, only 2 matches:

daemon:*:1:
sys:*:3:
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
gavenkoa
  • 521
  • 6
  • 11
  • This sort of thing is where [configuration management tools](https://cfengine.com/learn/why-cfengine/) come into play. (I've linked to the one I use and highly prefer for scale and security.) – Wildcard Mar 30 '16 at 15:46
  • 1
    You probably don't want to change group ID's of the OS users/groups. But yeah in an enterprise environment, the non-OS user/service UID's/GID's would be standardized. For personal use probably the best you can do is set r/w for world on the files. – Bratchley Mar 30 '16 at 15:49

3 Answers3

2

As you've discovered, there is no standard for username-uid and groupname-gid mapping. Even commonly-used system accounts that are not part of the base system can have different uids or gids on systems running the exact same OS; it depends on the order in which the packages were installed. The packages often just use getent passwd username || useradd username during installation.

So the best bet is to choose your own uids and gids, outside of the system range.

On some systems, there will be a configuration file such as /etc/login.defs with entries such as:

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN                  1000
UID_MAX                 60000
# System accounts
SYS_UID_MIN               201
SYS_UID_MAX               999

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN                  1000
GID_MAX                 60000
# System accounts
SYS_GID_MIN               201
SYS_GID_MAX               999

Choose anything within the non-SYS ranges. One possibility is to use the range 59001..59999 for site-wide administrative use. You could then edit the login.defs file to set UID_MAX and GID_MAX to 59000, to avoid any conflicts.

Mark Plotnick
  • 24,913
  • 2
  • 59
  • 81
  • I haven't tried this, but if the 60000 is the max value of **automatic** uid/gid selection, wouldn't manually assign 60001 and above be a better choice than 59001..59999? – zypA13510 Aug 23 '19 at 09:26
  • 1
    @zypA13510 IDs above 60000 may be allocated by system programs, too, despite the implication in login.def's comments. [Systemd uses the range 61184…65519](https://systemd.io/UIDS-GIDS.html). (I ought to edit the answer to note this.) If you interoperate with Solaris, it uses 60001 and 60002 for some system users. Above 70000 is probably OK, but I think it's safer to just lower UID_MAX in login.defs and then manually allocate IDs in the range [UID_MAX+1..59999]. – Mark Plotnick Aug 23 '19 at 15:16
1

I discover that sys group share id 3 on Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

No other groups name share same id. Even root group with id 0 on some systems actually is wheel. And nogroup on Linux is usually 65534 but on NetBSD is 32766. Different distros have different human readable names for this group, like: nogroup (Debian), nfsnobody (RedHat), nobody (FreeBSD), nobody (MacOS).

POSIX, SUSv4, LSB, etc specs are not defines group ids.

sys marked as obsolete in Debian docs.

With sys group and setgid bit and ACL it is possible to make ext4 volume move between hosts without warring about permissions after:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chgmod -R g+s /mnt/data/dir
$ sudo fsetacl -R -m g:sys:rwx /mnt/data/dir
$ sudo fsetacl -R -d -m g:sys:rwx /mnt/data/dir
gavenkoa
  • 521
  • 6
  • 11
1

There are no conventions regarding group ids. Authorization configuration is generally considered part of local policy, and typically has nothing to do with entries in a local /etc/passwd or /etc/group file.

Groups used for authorization decisions typically come from a centralized directory (LDAP, AD, etc) and will differ from organization to organization, and have no relationship to the distribution (or operating system) in use.

larsks
  • 32,449
  • 5
  • 54
  • 70