11766 2017-07-06 15:48:06 +0000 "nobody" group added by systemd sysusers.d 2023-03-31 12:08:54 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED FIXED Medium+ normal 4.2 M4 1 patrick.ohly p.lobacz cinly.ooi meta.mr.watcher meta.watcher p.lobacz Qi.Chen randy.macleod rebecca.swee.fun.chang richard.purdie sgw yi.zhao --- --- No (bug/feature does not impact docs) oldest_to_newest 74833 0 patrick.ohly 2017-07-06 15:48:06 +0000 systemd has: # grep nobody /usr/lib/sysusers.d/basic.conf # The nobody user for NFS file systems u nobody 65534 "Nobody" - At runtime, that creates a group "nobody" because there is no such group in the base configuration. Adding that group causes /etc/group to differ from what was in the original image, which causes OSTree to stop updating the file because it looks like it was modified by a local admin. systemd_create_users() from rootfs-postcommands.bbclass looks at these systemd configuration files, but it doesn't create the group, probably because there is already a "nobody" user in /etc/passwd. I think the right solution would be to have both a "nobody" user and group. 78565 1 yi.zhao 2017-12-07 08:12:56 +0000 I'm not sure if it is a good idea to add nobody group. For sysVinit, we follow the Debian rule which doesn't have nobody group and the nobody user's group is "nogroup" group. Should we have to break this rule to add nobody group for systemd ? And for systemd, although it create nobody group with systemd-sysusers, the nobody user's group is not changed, still nogroup. That means no one belongs to this group. My preferred solution is to pass "--with-nobody-group=nogroup" to systemd configure to ensure the systemd doesn't create nobody group and also follow the Debian rule. Another similar situation is wheel group, there is no such group in debian rule but systemd create it. 78567 2 patrick.ohly 2017-12-07 09:23:09 +0000 If systemd already supports running without a nobody group, then I agree that this is the right solution. Same for wheel. 78678 3 yi.zhao 2017-12-12 03:29:53 +0000 I had built core-image-sato-sdk image and found there are 3 groups adding by systemd-sysusers: nobody, wheel, kvm. Someone sent a patch for adding wheel group in systemd to oe-core but it is still pending. For Debian, in order to avoid creating groups, it doesn't ship /usr/lib/sysusers.d/basic.conf to the system. I don't think this is a good solution for Yocto. For the end users, if you want to avoid creating these groups, I suggest to remove PACKAGECONFIG for sysusers when building. It should be safe. 87044 4 randy.macleod 2020-04-16 08:27:06 +0000 Yi please re-submit. 89923 5 randy.macleod 2021-04-13 02:35:53 +0000 Set a specific milestone target. Yi please get this one under discussion to see if we are going to reject it or not. 91023 6 yi.zhao 2021-07-27 04:28:47 +0000 On current Yocto 3.4, there are 4 extra groups added by systemd: wheel,render,sgx,nobody. For the end users, if you want to avoid creating these groups, I suggest to remove PACKAGECONFIG for sysusers when building. 95045 7 p.lobacz 2023-03-02 15:19:54 +0000 I think I have found why it is caused in issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=15046 95053 8 randy.macleod 2023-03-02 16:17:12 +0000 Do we need this bug and https://bugzilla.yoctoproject.org/show_bug.cgi?id=15046 or can one be closed? 95055 9 p.lobacz 2023-03-02 19:16:21 +0000 (In reply to comment #8) > Do we need this bug and > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15046 > or can one be closed? I think we can close it and I can commit a patch with the fix to the list 95056 10 randy.macleod 2023-03-02 20:22:15 +0000 Piotr, We like to have a link to the oe-core commit in the comments here so I've left this open for a bit longer. Once the change is merged add a link and set the Status to Resolved / Fixed please. 95129 11 p.lobacz 2023-03-14 11:14:05 +0000 (In reply to comment #10) > Piotr, > We like to have a link to the oe-core commit in the comments here so I've > left this open for a bit longer. Once the change is merged add a link and > set the Status to Resolved / Fixed please. Randy I have sent a patch to the mailing list. Please verify it(In reply to Randy MacLeod from comment #10) > Piotr, > We like to have a link to the oe-core commit in the comments here so I've > left this open for a bit longer. Once the change is merged add a link and > set the Status to Resolved / Fixed please. Randy I have sent a patch with git send-email but it is not yet visible on the list 95131 12 p.lobacz 2023-03-14 14:21:27 +0000 OK Randy I have finally succeeded. Haven't noticed that I need to be subscribed to the mailing list... This is the link with the patch fix https://lists.openembedded.org/g/openembedded-core/message/178491 95246 13 randy.macleod 2023-03-30 20:08:13 +0000 Piotr, I should remember to mention that you need to be subscribed to the list. Oops. Your commit is on master: https://git.openembedded.org/openembedded-core/commit/?id=d69fccf2e5d108dd7c6059310924588d36a45865 ❯ git branch -a --contains d69fccf2e5d108dd7c6059310924588d36a45865 * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/master-next and is making it's way back to the langdale and kirkstone branches. So I'm marking it as resolved. Thanks! 95255 14 p.lobacz 2023-03-31 12:08:54 +0000 Your welcome Randy :)