Is systemd's logind or Gnome-wayland-session incompatible with hidepid=2?

Question

Is there any documentation regarding systemd which would suggest that setting the hidepid=2 mount option to the /proc procfs will cause problems?

the error message part before the failure to start a Gnome wayland session is:

systemd[330]: Started D-Bus User Message Bus.
gnome-session[339]: gnome-session-binary[339]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting use
gnome-session-binary[339]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
gnome-session[339]: gnome-session-binary[339]: WARNING: Could not parse desktop file orca-autostart.desktop or it references a not found TryExec binary
gnome-session-binary[339]: WARNING: Could not parse desktop file orca-autostart.desktop or it references a not found TryExec binary
gnome-shell[346]: Can't initialize KMS backend: Could not get session ID: No such file or directory
gnome-session[339]: gnome-session-binary[339]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gnome-session-binary[339]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gnome-session-binary[339]: Unrecoverable failure in required component org.gnome.Shell.desktop
gdm[296]: GdmDisplay: display lasted 0.735810 seconds

I guess that the session Id is acquired somehow via the PID, which is not visisble to gnome-session.

The problem is occurring on an Arch Linux distribution. However I do think it is linked to upstream problems. It seems as discussed on Gentoo's Wiki "GNOME without systemd" that especially the wayland session of Gnome is coupled very much with systemd.

It seems to be the combination of systemd's logind, with hidepid=2 procfs mount option interplaying with Gnome wayland session, more so than Gnome Xorg session, relying on the logind.

I have also followed the advice given in @sourcejedi answer and made the /etc/fstab exemption for logind. So my this is my entry in /etc/fstab

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

where 26 is the GID of the proc group to which logind, respectively polkitd group was added. However this did not resolve the problem.

As shown at https://www.freedesktop.org/wiki/Software/systemd/logind/

  interface org.freedesktop.login1.Manager {
    methods:
      GetSession(in  s session_id,
                 out o object_path);
      GetSessionByPID(in  u pid,
                      out o object_path);

it seems the SessionID might be queried using the PID, which naturally might create Problems once hidepid=2 option is used.

I'm 99.9% sure gnome-session is trying to read it's own session ID, which it expects to have been assigned already in pam_systemd. In an ancestor process such as gdm. — sourcejedi, Jun 13 '17 at 13:01
pam_systemd sets the environment variable `XDG_SESSION_ID` when you log in... I guess gdm has to create its own PAM session for the login screen as well. On my system I see `/etc/pam.d/gdm-launch-environment`, which uses `pam_permit` in place of any authentication. Apparently it is also possible to query the session for a given PID - but this works by sending a dbus request (GetSessionByPID) to systemd-logind, so that's the process that has to actually find the ID. The command `loginctl session-status` must be using this dbus method. — sourcejedi, Jun 13 '17 at 13:06

sourcejedi · Answer 1 · 2017-06-12T08:28:44.467

4

https://wiki.archlinux.org/index.php/Security#hidepid

For Xorg to work, an exception needs to be added for systemd-logind:
/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service]
SupplementaryGroups=proc

EDIT: this documentation does not explain why it would be necessary. Looking at the upstream systemd-logind.service, the service unit does not run as a separate user. (hidepid is generally described as not applying to root). However from the code, I think hidepid actually uses a capability CAP_SYS_PTRACE. And the systemd-logind.service limits itself to a set of capabilities, which do not include CAP_SYS_PTRACE.

Anyway, this implies that Arch Linux' systemd PID 1 is able to boot OK with hidepid. Personally I would worry about needing this "exception" even without Xorg, in case of other software that used the same systemd-logind features.

edited Jun 12 '17 at 08:28

answered Jun 12 '17 at 08:09

sourcejedi

48,311
17
143
296

1

Indeed arch can boot alright. Looking at the error messages in journalctl it seems that gnome-session cannot get the logind sessin id, in case the `hidepid=2` is set, even when I granted the exception to the procfs. It can be that systemd is not even the culprit but hence Gnome. – humanityANDpeace Jun 13 '17 at 06:52
@humanityANDpeace weird! I can't think of anything, but if you want to narrow things down you should post the actual error messages :). – sourcejedi Jun 13 '17 at 08:37
@humanityANDpeace the updated question should show the specific exemption you made, the fact that you are using arch linux, and absolutely needs to include an indication of the versions or at least date that the relevant software comes from. (One reason is that QAs are a reference to be referred to by others in future). – sourcejedi Jun 13 '17 at 12:47

Is systemd's logind or Gnome-wayland-session incompatible with hidepid=2?

1 Answers1