[241] "No such process" when starting user instance with hidepid=2 and cgroupv2

[yadutaf]

systemd version the issue has been seen with

241

Used distribution

Yocto, with an additional "-Ddefault-hierarchy=unified" build flag

Expected behaviour you didn't see

user@xxxx.service should start

Unexpected behaviour you saw

user@xxxx.service is in state failed with the following logs

root@machine:~# systemctl status user@xxxx.service
● user@xxxx.service - User Manager for UID xxxx
   Loaded: loaded (/lib/systemd/system/user@.service; static; vendor preset: enabled)
   Active: failed (Result: protocol) since Thu 2019-07-04 09:00:23 UTC; 2min 28s ago
     Docs: man:user@.service(5)
  Process: 1433 ExecStart=/lib/systemd/systemd --user (code=exited, status=1/FAILURE)
 Main PID: 1433 (code=exited, status=1/FAILURE)
      CPU: 5ms

Jul 04 09:00:23 machine systemd[1]: Starting User Manager for UID xxxx...
Jul 04 09:00:23 machine systemd[1433]: Failed to determine supported controllers: No such process
Jul 04 09:00:23 machine systemd[1433]: Failed to allocate manager object: No such process
Jul 04 09:00:23 machine systemd[1]: user@xxxx.service: Failed with result 'protocol'.
Jul 04 09:00:23 machine systemd[1]: Failed to start User Manager for UID xxxx.
Jul 04 09:00:23 machine systemd[1]: user@xxxx.service: Consumed 5ms CPU time.

Steps to reproduce the problem

1. mount -oremount,gid=4,hidepid=2 /proc
2. /bin/loginctl enable-linger user-xxxx

We are using the "unified" hierarchy, not sure whether it makes any difference

Workaround

This can be worked-around by adding SupplementaryGroups=4 to

• user@.service
• systemd-logind.service

(Original hint from https://github.com/pld-linux/systemd/blob/master/proc-hidepid.patch)

But, in this case, all user processes created by systemd user instance have the supplementary group 4, which reduces the usefulness of the 'hidepid=2' feature. It does not however affect sessions opened via SSH so that there is still some benefit :)

Is there any way to avoid propagating the supplementary group to the child processes or, is there a way to avoid needing the patch at least on the user@.service (which I believe, would 'fix' the 'leak') ? I'd naively imagine that the user instance could query the system instance for the info it needs :)

Thanks,

[poettering]

Sorry, but hidepid= is simply not supported on systemd instances. we require the ability to identify remote processes and most of our services run at minimal privileges, and this means this cannot work. Sorry.

There has been work on making hidepid= a true mount option (i.e. an option of the mount itself instead of the pidns), but it stalled. If we ever get that we could have a per-service hidepid= which would make things a lot more useful.

But anyway, sorry. hidepid= the way it is is not compatible with systemd, and that's not going to change.

[poettering]

The patch set I was talking of is this:

https://lwn.net/Articles/738597/

If you are interested in this, please work with the kernel folks, resurrect the patch set, and try to make it work.

[yadutaf]

Thanks for your quick reply !

I understand Systemd requires to see all PIDs on the system and it's fine. Maybe there could be a way to start the systemd user instance with CAP_SET_GID and instruct it to drop the additional group (4 in my case) either when it no longer needs it (if this time exists), either before exec-ing a non-systemd binary.

Would it make sense ?

[poettering]

It's not just systemd, it's a lot of other stuff we require. Polkit/dbus for example and so on...

I think the clean fix would be to fix the kernel to make hidepid not a system-wide setting, see above. Instead of patching around in systemd, just fix this properly by patching around in the kernel.

[yadutaf]

I was able to hack something which works in my use case with:

1. A hackish patch on the kernel (4.9)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index ae6d4aa65c8f..11163b7bbe4d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -675,11 +675,14 @@ int proc_setattr(struct dentry *dentry, struct iattr *attr)
 /*
  * May current process learn task's sched/cmdline info (for hide_pid_min=1)
  * or euid/egid (for hide_pid_min=2)?
+ * jean-tiare: Hack for systemd user instance: Always allow PID 1.
  */
 static bool has_pid_permissions(struct pid_namespace *pid,
 				 struct task_struct *task,
 				 int hide_pid_min)
 {
+	if (task->pid == 1)
+		return true;
 	if (pid->hide_pid < hide_pid_min)
 		return true;
 	if (in_group_p(pid->pid_gid))

2. A drop in for systemd-logind.service

# Grant full access to all PIDs to systemd-logind
[Service]
SupplementaryGroups=4

With both patches, the full test suite passes on my side. Systemd user instances are working fine and the started process have only access there own PIDs and PID 1. This may be missing a lot of (corner ?) cases but this suggests that 'hidepid' support in systemd is not very far and might not require a rework in /proc. Not sure if proposing a new mount flag like "showpid1" for procfs would be acceptable on the kernel side though.

[Zocker1999NET]

I fixed it on Linux 5.10 without patching the kernel, only by creating a special group proc, which has access to all process information by using following configuration in /etc/fstab with gid=proc:

proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0

Then, to allow systemd-logind to access all processes, add a drop-in config for systemd-logind.service adding the supplement group proc to systemd-logind:

[Service]
SupplementaryGroups=proc

After restarting the computer (or restarting systemd-logind), everything worked fine like before enabling hidepid=2 as I observed it.