O logind do systemd ou a sessão do Gnome-wayland são incompatíveis com o hidepid = 2?

Question

Existe alguma documentação referente a systemd , que sugere que a configuração da opção hidepid=2 mount para o /proc procfs cause problemas?

a parte da mensagem de erro antes da falha ao iniciar uma sessão do Gnome é:

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

Eu acho que o ID da sessão é adquirido de alguma forma através do PID, que não é visível para a sessão do gnome.

O problema está ocorrendo em uma distribuição do Arch Linux. No entanto, penso que está ligado a problemas a montante. Parece como discutido em Wiki do Gentoo "GNOME sem systemd" que especialmente a sessão de wayland do Gnome está muito ligada a systemd.

Parece ser a combinação da systemd ' logind ', com hidepid=2 procfs mount interagindo com a Gnome wayland session, mais do que a sessão do Gnome Xorg, contando com o logind.

Eu também segui o conselho dado na resposta do @sourcejedi e fiz o Isenção do / etc / fstab para logind. Então, esta é minha entrada em /etc/fstab

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

em que 26 é o GID do grupo proc ao qual o logind, respectivamente o grupo polkitd foi adicionado. No entanto, isso não resolveu o problema.

Como mostrado no link

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

parece que o SessionID pode ser consultado usando o PID, o que naturalmente pode criar problemas quando a opção hidepid=2 for usada.

    

Answer 1

link

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: esta documentação não explica por que isso seria necessário. Observando o systemd-logind.service a montante, a unidade de serviço não não é executado como um usuário separado. (hidepid é geralmente descrito como não se aplicando a root ). No entanto, no código , acho O hidepid realmente usa um recurso CAP_SYS_PTRACE. E o systemd-logind.service limita-se a um conjunto de recursos, que não incluem CAP_SYS_PTRACE.

De qualquer forma, isso implica que o systemID PID 1 do Arch Linux é capaz de inicializar OK com o hidepid. Pessoalmente, eu me preocuparia em precisar dessa "exceção", mesmo sem o Xorg, no caso de outros softwares que usassem os mesmos recursos do systemd-logind.