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
Opened by userwithuid (userwithuid) - Sunday, 10 December 2017, 17:14 GMT
Last edited by Toolybird (Toolybird) - Thursday, 08 June 2023, 06:35 GMT
|
Details
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? [1] https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database [2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/useradd.defaults?h=packages/shadow&id=5e62a1912ef9473598d494957192522bb9f408c3 [3] https://git.archlinux.org/svntogit/packages.git/tree/trunk/util-linux.sysusers?h=packages/util-linux&id=7d55cb1dcafdd6b2b657fbb0f4bce4bb6967cfce |
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
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
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.
https://github.com/systemd/systemd/commit/84786b8e322f916b78aeb81f409ea3500dd49143
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).
Thanks for the "users" info. We should add this in the next systemd version.
A.
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.
B.
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. :-)
[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cups&id=1e9f4ac655b246df442b6d8c461e07722749a30b
[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/sysusers?h=packages/filesystem&id=ea887f33c7cf530a4eba995aae575b962062626a
FS#56316already existed for the "users" group at least.https://github.com/systemd/systemd/pull/7973