Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 696930 - sys-power/upower-0.99.11 should check for kernel option CONFIG_USER_NS
Summary: sys-power/upower-0.99.11 should check for kernel option CONFIG_USER_NS
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Freedesktop bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-08 05:37 UTC by rnddim
Modified: 2020-09-24 14:51 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rnddim 2019-10-08 05:37:27 UTC
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.
Comment 1 Mike Gilbert gentoo-dev 2019-10-08 16:23:49 UTC
PrivateUsers=yes was introduced here.

https://cgit.freedesktop.org/upower/commit/src/upower.service.in?id=1c6a6bfbbb01aa92b4550c1e3a087b1c0f7ef310
Comment 2 Mike Gilbert gentoo-dev 2019-10-08 16:25:00 UTC
It might make more sense to check for USER_NS in the sys-apps/systemd ebuild.
Comment 3 rnddim 2019-10-08 16:38:14 UTC
(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.
Comment 4 Mike Gilbert gentoo-dev 2019-10-08 16:53:58 UTC
(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.
Comment 5 Mike Gilbert gentoo-dev 2019-10-08 17:08:28 UTC
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.
Comment 6 Pacho Ramos gentoo-dev 2019-11-19 11:46:57 UTC
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
Comment 7 contactopublico57 2019-12-26 23:04:57 UTC
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.
Comment 8 Larry the Git Cow gentoo-dev 2020-09-24 14:51:28 UTC
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(-)