Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#56662 - [systemd][shadow] Predictable uids/gids with systemd-sysusers

Attached to Project: Arch Linux
Opened by userwithuid (userwithuid) - Sunday, 10 December 2017, 17:14 GMT
Last edited by Toolybird (Toolybird) - Thursday, 08 June 2023, 06:35 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Since filesystem 2017.10-2, Arch relies on systemd upstream's {basic,systemd*}.conf for many default sysusers and groups. The files in question do not specify uids/gids for the most part, meaning that new installs will not have predictable ones starting with the next arch iso release.

Has this situation been discussed before/is this an intended change? As far as I can see, there are 2 paths, neither of them currently implemented:

Option 1: Arch considers ids to always be unpredictable/not portable/an implementation detail (except root 0, sysusers 1-999, regular users 1000+).

Option 2: Arch considers ids to be predicatable by default for packages in the offical repos. Those not assigned yet in [1] should eventually get some.

If opt1 is the intended goal, sysusers.d/arch.conf keeping explicit uids seems rather odd? Then again I don't think the (so far only partial) change has been tested across the repos yet. A quick example/bug I came across today was a warning from useradd because the config expects the gid for "users" to be 100 [2], but basic.conf doesn't specify it. So maybe it was good to delay moving further in this direction until it get's more testing?

If opt2 is preferable, I would suggest to immediately (=before the next arch iso release) modify/override {basic,systemd*}.conf to retain the predictable uids/gids that used to be in filesystem. Also make sure that other packages in core are OK too (e.g. rfkill used to be gid 24, but now it's variable [3]). Eventually, pkgs in extra/community should 1. move from useradd in *.install to sysusers.d and 2. set explicit ids in the long run.

What's the sentiment on this?

This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 08 June 2023, 06:35 GMT
Reason for closing:  Fixed
Additional comments about closing:  Old and stale. 5 years later this is all under control in the filesystem pkg with sysusers.d
Comment by Eli Schwartz (eschwartz) - Sunday, 10 December 2017, 17:25 GMT
The UID/GID database is meant for users/groups that actually need to be a specific id, for example because software hardcodes assumptions about the id. Do you have examples of where this is the case? If so, please list them and we can deal with them on a case-by-case basis.

Yes, the general move towards dynamic ids is intended. Hardcoding things without due cause is bloated and silly.
So assume option 1.

The "users" example seems interesting, but only takes effect on new installs so maybe it wasn't immediately apparent. :D
However, it is created by basic.conf which is generated automatically by systemd.
Comment by userwithuid (userwithuid) - Sunday, 10 December 2017, 18:45 GMT
Wrt the users gid, I just saw upstream has this covered now :-)

As far as the options go: One advantage of opt2 I discovered is that it makes resetting etc/{passwd,group} quite painless. With dynamic ids you have to find and chown files after a reset as they will have the a different id (and for the chown you have to know what username the files are supposed to be owned by). With predictable ids + sysusers I was able to start a fresh passwd/group at runtime! without even rebooting, which I found pretty neat.

Also, thinking about this more, maybe I forgot option 1.5: Give fixed ids only to users/groups that will own non-transient files, the others (like rfkill or all the udev/hardware related ones in basic.conf can be dynamic).
Comment by Eli Schwartz (eschwartz) - Sunday, 10 December 2017, 18:50 GMT
  • Field changed: Task Type (Feature Request → Bug Report)
  • Field changed: Summary ([filesystem][systemd] Predictable uids/gids with systemd-sysusers → [systemd] Predictable uids/gids with systemd-sysusers)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Severity (Very Low → Low)
  • Task assigned to Dave Reisner (falconindy), Christian Hesse (eworm)
Well, yeah -- hardcoded uids only have "due cause" when they own packaged files. So like I said, if you find any, please do tell us!

Thanks for the "users" info. We should add this in the next systemd version.
Comment by Eli Schwartz (eschwartz) - Sunday, 10 December 2017, 18:53 GMT
  • Field changed: Summary ([systemd] Predictable uids/gids with systemd-sysusers → [systemd][shadow] Predictable uids/gids with systemd-sysusers)
Alternatively, consider why this is hadcoded at all. Perhaps because of similar cases to this?
Comment by userwithuid (userwithuid) - Sunday, 10 December 2017, 21:24 GMT
OK, will report back do if I get the time to test more.


Here's one to start with: cups relies on the "lp" group both for packaged [1] and unpackaged (/etc printer configs, spool, log) files. "lp" used to be gid 7 but basic.conf does not specify a gid now.

Most of the other things I saw in my test setup were I think non-critical. They would be adjusted after a reboot/service restart and mostly just leave old/rotated log files or old cache files with "wrong" ids behind.


Another thing I noticed: sysusers.d/arch.conf [2] tries to handle the legacy uid/gid mismatch for ftp and mail, but this does not seem to work.

On my test setups, "ftp" gets 11:11 so the attempted uid 14 part is ignored. Same for "mail" 12:12 vs uid 8.

Please don't fix this though, it's nicer when they match, just remove the attempted workaround. :-)

Comment by Eli Schwartz (eschwartz) - Monday, 11 December 2017, 00:36 GMT
Oh, looks like  FS#56316  already existed for the "users" group at least.
Comment by Dave Reisner (falconindy) - Monday, 11 December 2017, 14:11 GMT
This sounds like a major regression which needs more planning on the filesystem side...
Comment by David McAdoo (geecroof) - Friday, 26 January 2018, 12:04 GMT
Systemd is going to have more versatile uid:gid matches in sysusers.d