The systemd upower.service failed to start when booting up my computer after installing upower-0.99.11. Searching found a debian bug report (provided in the URL field) which indicated the need for CONFIG_USER_NS to be set in the kernel. Setting CONFIG_USER_NS to yes and booting up with the newly-compiled kernel allows the upower service to start up as expected. I don't know if this failure to start only occurs with systemd-based systems (since there appears to be a specific option in the upower.service file that requires this kernel setting), but I suspect upower now needs CONFIG_USER_NS regardless of what kind of init system you have. The upower-0.99.11 ebuild should check for CONFIG_USER_NS and warn (maybe even fail?) if this option is not enabled. It's worth noting that the kernel help text for CONFIG_USER_NS also suggests CONFIG_MEMCG to be enabled, but this is not necessary for upower to start. Reproducible: Always Steps to Reproduce: 1. Boot computer with a kernel with CONFIG_USER_NS set to no. 2. Check the status of upower with `systemctl status upower` Actual Results: upower.service is not active, and a couple lines of error messages are listed. Expected Results: upower.service is active and running, no errors.
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(-)
