| Summary: | "nobody" group added by systemd sysusers.d | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Patrick Ohly <patrick.ohly> |
| Component: | core | Assignee: | Piotr Łobacz <p.lobacz> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | cinly.ooi, meta.mr.watcher, meta.watcher, p.lobacz, Qi.Chen, randy.macleod, rebecca.swee.fun.chang, richard.purdie, sgw, yi.zhao |
| Version: | unspecified | ||
| Target Milestone: | 4.2 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Patrick Ohly
2017-07-06 15:48:06 UTC
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. If systemd already supports running without a nobody group, then I agree that this is the right solution. Same for wheel. 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. Yi please re-submit. Set a specific milestone target. Yi please get this one under discussion to see if we are going to reject it or not. 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. I think I have found why it is caused in issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=15046 Do we need this bug and https://bugzilla.yoctoproject.org/show_bug.cgi?id=15046 or can one be closed? (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 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. (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 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 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! Your welcome Randy :) |