4

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:
Improve this question
2
  • This sort of thing is where configuration management tools come into play. (I've linked to the one I use and highly prefer for scale and security.) Commented Mar 30, 2016 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. Commented Mar 30, 2016 at 15:49

3 Answers 3

Reset to default
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.

Improve this answer
2
  • 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? Commented Aug 23, 2019 at 9: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. (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]. Commented Aug 23, 2019 at 15:16
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.

Improve this answer
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
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.