systemd's default groups (video, wheel, etc) are created by systemd itself based on its own configuration values, and not via USERADD. This sidesteps any possible static uid/gid assignment via useradd-staticids. Systemd uses its /usr/lib/sysusers.d/basic.conf [1] (and some other .conf files in there) for creating users/groups. Most groups/users can be configured to be static via meson options (e.g. -Dvideo-gid=123) [2], but by default they are dynamically assigned, with the sole exception of tty with gid 5. This can be most easily observed by defining a group id for wheel via files/group and a different (via USERADD added) group with a lower id, then looking at the resulting groups file. The wheel group will always have the lowest 9xx group, and not the id from files/group. Any group id for wheel that is more than one lower than the lowest other 9xx group will likely also show the issue. [1] https://github.com/systemd/systemd/blob/main/sysusers.d/basic.conf.in [2] https://github.com/systemd/systemd/blob/main/meson_options.txt#L286-L327
There's obviously some overlap with the groups from base-passwd, so the dynamic assignment from systemd doesn't happen for most groups, but for some it does. Thinking about it, base-passwd's default static group and user ids are probably also unaffected by useradd-staticids, but that is less of an issue since they are static by default already.
Jonas, Valid bug. Are you able to send a fix to the oe-core list?
If I felt I had the capability to solve that, I would have sent a fix without opening a bug ;P All joking aside, this is a bit out of my depth for Yocto/OE, and I wouldn't even know how to approach this, apart from currently not having too much time to spend on it. I can test things though. Since there is a workaround for that (append the systemd recipe with meson args), it isn't urgent for me to get it fixed. So this bug report is mostly for documentation purposes from my point of view (getting it fixes of course is nice). P.S: Was setting this to RESOLVED FIXED intentional?
Hi Jonas, Thanks for the small joke... It's the end of another long day and I do actually appreciate it! No, I inadvertently move it to Fixed so I'm resetting the status so we'll review the defect again at next Thursday's YP bug review meeting. Thanks.
Add some info. Hope it helps. There's a systemd_sysusers_check function in rootfs-postcommands.bbclass. This function will ensure that the passwd/group files match the sysuser.d/*.conf definitions. So if things do not match, e.g., the wheel group id differs, there will be a warning. The problem you gets is that base-passwd does not match the custom uid/gid assignments passed in by config options. By default, the value is '-' for basic.conf.in, systemd just ensures that these users and groups exist. Let me use the wheel group as an example: meta/recipes-core/base-passwd/base-passwd/0007-Add-wheel-group.patch:+wheel:*:80: meta/recipes-core/base-passwd/base-passwd_3.6.5.bb: file://0007-Add-wheel-group.patch \ You can see that there's patch for base-passwd to add a wheel group of gid 80. By default, what systemd recipe generates is: $ grep wheel usr/lib/sysusers.d/basic.conf g wheel - - - But if you pass a different gid to systemd recipe, things don't match. And in such case you will get a warning at rootfs time. Note that useradd-static only handles USERADD/GROUPADD commands. So groups such as wheel, as they are defined in base-passwd instead of being added by GROUPADD command, useradd-static will not handle it. If you want to use a different uid/gid for some user/group that has already been definied in bass-passwd, you need to add two bbappend files, bass-passwd and systemd, giving them the same uid/gids. To make things clear, useradd-staticids cannot change the uid/gids that are predefined in bass-passwd. @randy, what we need to sort out is the definition of staticids. The key question is: whether the settings in it should take precedence over base-passwd. It's easy to adjust base-passwd recipe if we determine so.
(In reply to Chen Qi from comment #5) > Add some info. Hope it helps. > > There's a systemd_sysusers_check function in rootfs-postcommands.bbclass. > This function will ensure that the passwd/group files match the > sysuser.d/*.conf definitions. So if things do not match, e.g., the wheel > group id differs, there will be a warning. > > The problem you gets is that base-passwd does not match the custom uid/gid > assignments passed in by config options. By default, the value is '-' for > basic.conf.in, systemd just ensures that these users and groups exist. > > Let me use the wheel group as an example: > > > meta/recipes-core/base-passwd/base-passwd/0007-Add-wheel-group.patch:+wheel: > *:80: > meta/recipes-core/base-passwd/base-passwd_3.6.5.bb: > file://0007-Add-wheel-group.patch \ > > You can see that there's patch for base-passwd to add a wheel group of gid > 80. Ah, indeed there is one in newer Yocto versions. These don't exist in kirkstone, which we are currently using, and I didn't double check base-passwd for master (only systemd). It might make sense to backport this patch to kirkstone as well. *That* is something I can do. > By default, what systemd recipe generates is: > $ grep wheel usr/lib/sysusers.d/basic.conf > g wheel - - - > > But if you pass a different gid to systemd recipe, things don't match. And > in such case you will get a warning at rootfs time. Right, setting these in the recipe is just a quick workaround for us to get a static gid for wheel in kirkstone, not something I would recommend in general. Updating/fixing up those .conf files would be better, and would also work for those gids/uids systemd doesn't even has any meson configuration variables. > Note that useradd-static only handles USERADD/GROUPADD commands. So groups > such as wheel, as they are defined in base-passwd instead of being added by > GROUPADD command, useradd-static will not handle it. > > If you want to use a different uid/gid for some user/group that has already > been definied in bass-passwd, you need to add two bbappend files, > bass-passwd and systemd, giving them the same uid/gids. > > To make things clear, useradd-staticids cannot change the uid/gids that are > predefined in bass-passwd. > > @randy, what we need to sort out is the definition of staticids. The key > question is: whether the settings in it should take precedence over > base-passwd. > It's easy to adjust base-passwd recipe if we determine so. I'm not Randy, but IMHO useradd-staticids should trump anything. Here the user explicitly states the uids/gids they expect the users and groups to have, and anything else would cause confusion and or (not so) silent breakage. At least it should warn if there is a conflict, so users are aware of it.
Ricahrd and YP Bug reviewers looked at this briefly. Jonas, can you backport the patch to kirkstone? For the mismatched staticids, they should just be hard errors to avoid having too much complication. Will you also send a patch for that?
Hm, I don't know why, but the reply I wrote a few days ago was eaten by a grue^W^W the system (or I just didn't send it correctly). (In reply to Randy MacLeod from comment #7) > Ricahrd and YP Bug reviewers looked at this briefly. > > Jonas, > can you backport the patch to kirkstone? https://patchwork.yoctoproject.org/project/oe-core/list/?series=30226 > For the mismatched staticids, they should just be hard errors to avoid > having too much complication. > > Will you also send a patch for that? Unfortunately definitely not this year, and I'm not sure when I'll have time looking into that next year.
Hi, (In reply to Jonas Gorski from comment #8) > Hm, I don't know why, but the reply I wrote a few days ago was eaten by a > grue^W^W the system (or I just didn't send it correctly). > > (In reply to Randy MacLeod from comment #7) > > Ricahrd and YP Bug reviewers looked at this briefly. > > > > Jonas, > > can you backport the patch to kirkstone? > > https://patchwork.yoctoproject.org/project/oe-core/list/?series=30226 These have been merged. > > > For the mismatched staticids, they should just be hard errors to avoid > > having too much complication. > > > > Will you also send a patch for that? > > Unfortunately definitely not this year, and I'm not sure when I'll have time > looking into that next year. I'm now back from vacation, but I would need assistance here on how to even approach this. My python-foo is non-existent. Best Regards, Jonas
The kirkstone backports have merged: https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=a20b02fdfe64c005f7587a1d9077bdc282f7b6b1 and a few more with date = 2024-12-18, that can be found in this list: https://git.openembedded.org/openembedded-core/log/?h=kirkstone&qt=grep&q=jonas.gorski%40bisdn.de There's more to do so I'll leave the defect open. Jonas, for the staticids problem it seems like the first step is to cause a hard error. If you send a patch to the list and CC me and Qi Chen, we could take a look. Qi is on New Year holiday starting next week so maybe you'll have time to learn a bit of python and try a very simple patch by the time he's back in mid February. If you really don't think you can take time for this, just let me know here. Thanks, ../Randy
Hi Randy, (In reply to Randy MacLeod from comment #10) > The kirkstone backports have merged: > > https://git.openembedded.org/openembedded-core/commit/ > ?h=kirkstone&id=a20b02fdfe64c005f7587a1d9077bdc282f7b6b1 > > and a few more with date = 2024-12-18, that can be found in this list: > > > https://git.openembedded.org/openembedded-core/log/ > ?h=kirkstone&qt=grep&q=jonas.gorski%40bisdn.de Right, that wasn't my first patch submission. ;p > > > There's more to do so I'll leave the defect open. > > Jonas, for the staticids problem it seems like the first step is to cause a > hard error. If you send a patch to the list and CC me and Qi Chen, we could > take a look. Qi is on New Year holiday starting next week so maybe you'll > have time to learn a bit of python and try a very simple patch by the time > he's back in mid February. If you really don't think you can take time for > this, just let me know here. I fear I won't really have the time until march. And it's less about python and more understanding the internals/design of bitbake/the classes, figuring out where to add the code, how to hook properly etc. On a related note, I noticed that newer Yocto versions already warns about if systemd sysusers use different UIDs/GIDs than the one from static-userids. Should this be an error if USERADD_ERROR_DYNAMIC is set to "error"? Should it also complain when they are dynamic? At least I would expect it to follow that. Best Regards, Jonas
Jonas, Take back if you have time to work on this bug. Thanks.