Summary: | sys-power/upower-0.99.11 should check for kernel option CONFIG_USER_NS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | rnddim |
Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | asturm, systemd |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.debian.org/939510 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
rnddim
2019-10-08 05:37:27 UTC
PrivateUsers=yes was introduced here. https://cgit.freedesktop.org/upower/commit/src/upower.service.in?id=1c6a6bfbbb01aa92b4550c1e3a087b1c0f7ef310 It might make more sense to check for USER_NS in the sys-apps/systemd ebuild. (In reply to Mike Gilbert from comment #2) > It might make more sense to check for USER_NS in the sys-apps/systemd ebuild. systemd only requires USER_NS if a service unit file uses PrivateUsers, according to the readme, so I think it would make sense to warn people when they're installing a package that makes use of the feature, instead of telling people that they *might* need to change their kernel settings every time they build systemd. Putting the warning in systemd would only make sense if you wanted people to update their kernel settings for every feature a systemd target/service/etc. file could decide to use. Also, if upower is setting PrivateUsers because it needs USER_NS to function, and it added Privateusers to ensure this feature was available, then obviously the check would have to be with upower, since it wouldn't matter what init system you used. Putting the check in systemd in this situation wouldn't help OpenRC users, for example. (In reply to rnddim from comment #3) > Also, if upower is setting PrivateUsers because it needs USER_NS to > function, and it added Privateusers to ensure this feature was available, > then obviously the check would have to be with upower, since it wouldn't > matter what init system you used. Putting the check in systemd in this > situation wouldn't help OpenRC users, for example. I'm fairly certain upower does not require USER_NS to function properly. According to the commit message PrivateUsers is just there as a general hardening measure. I would not be surprised if distros revert the change due to intentional lack of support in their kernels. Thinking about this... If we add a kernel check to sys-power/upower, we would only want to display it if the system is using systemd. sys-power/upower currently installs systemd units unconditionally, and does not have IUSE="systemd". So, a couple of options: 1. Add IUSE="systemd" to sys-power/upower just for the kernel check. 2. Check to see if the system is booted using systemd before performing the kernel check. Last time I checked, Fedora (RedHat) is updating many unit files to this hardening, hence, I guess that the amount of unit files using this features would increase a lot in the future. As a consequence... I would add the warning to systemd instead of on every package providing a unit with this concrete feature enabled. Is there a problem with enabling that option? I think I needed to enable it recently for chromium too if I don't misremember Note that the systemd related problem has not yet been resolved by Red Hat devs after a package version bump in Fedora rawhide, although it has long been reported there. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=431a568d06963207495c099b5a64f85442017507 commit 431a568d06963207495c099b5a64f85442017507 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-09-24 14:51:17 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-09-24 14:51:17 +0000 sys-apps/systemd: add kernel check for CONFIG_USER_NS Closes: https://bugs.gentoo.org/696930 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/systemd/systemd-245.7-r1.ebuild | 2 +- sys-apps/systemd/systemd-246-r1.ebuild | 2 +- sys-apps/systemd/systemd-9999.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) |