pam_systemd: set environment variables even if 'Already running in a session or user slice'

[cgzones]

systemd version the issue has been seen with

245.2-1

Used distribution

Debian sid

Expected behaviour you didn't see

$ systemctl --user status
● debianBullseye
   State: running
    Jobs: 0 queued
  Failed: 0 units
   Since: Thu 2020-03-26 00:06:59 CET; 29min ago
  CGroup: /user.slice/user-0.slice/user@0.service
          └─init.scope 
            ├─577 /lib/systemd/systemd --user
            └─579 (sd-pam)

Unexpected behaviour you saw

systemctl --user status
Failed to connect to bus: No such file or directory

Steps to reproduce the problem

1. Login as root
2. Switch SELinux context via newrole(1)

pam_systemd logs in debug mode:

Mar 26 00:27:03 debianBullseye newrole[1082]: pam_unix(newrole:session): session opened for user root by root(uid=0)
Mar 26 00:27:03 debianBullseye newrole[1082]: pam_systemd(newrole:session): pam-systemd initializing
Mar 26 00:27:03 debianBullseye newrole[1082]: pam_systemd(newrole:session): Asking logind to create session: uid=0 pid=1082 service=newrole type=tty class=user desktop= seat= vtnr=0 tty=pts/0 display= remote=no remote_user= remote_host=
Mar 26 00:27:03 debianBullseye newrole[1082]: pam_systemd(newrole:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a
Mar 26 00:27:03 debianBullseye newrole[1082]: pam_systemd(newrole:session): Not creating session: Already running in a session or user slice

Resulting environment:

$ env | grep XDG

Connecting to user instance:

$ systemctl --user status
Failed to connect to bus: No such file or directory

Setting XDG_RUNTIME_DIR manually:

$ export XDG_RUNTIME_DIR=/run/user/0

Connecting to user instance:

systemctl --user status
● debianBullseye
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2020-03-26 00:06:59 CET; 36min ago
   CGroup: /user.slice/user-0.slice/user@0.service
           └─init.scope 
             ├─577 /lib/systemd/systemd --user
             └─579 (sd-pam)

[topimiettinen]

I'm not sure there should be a new session because the UID does not change. Did you use -p|--preserve-environment flag?

Maybe restore_environment in newrole could handle XDG_* environment variables specially like it now handles TERM, DISPLAY and XAUTHORITY.

[cgzones]

I'm not sure there should be a new session because the UID does not change.

I am not suggesting to create a new session.

Did you use -p|--preserve-environment flag?

They do indeed prevent the environment from being cleaned.

Maybe restore_environment in newrole could handle XDG_* environment variables specially like it now handles TERM, DISPLAY and XAUTHORITY.

This feels to me like outsourcing a fix.

[topimiettinen]

Is there a change in behaviour, did this work with earlier versions of systemd?

This feels to me like outsourcing a fix.

I'm just probing if this is a problem with newrole, systemd or if there is a bug at all.

[poettering]

what does newrole do? flush env block, change selinux context, re-invoke PAM session hooks? why does it do the env block flushing and re-invoking of PAM session hooks?

[topimiettinen]

I'm not sure there should be a new session because the UID does not change.

I am not suggesting to create a new session.

This is however what happens when newrole is compiled with NAMESPACE_PRIV=y, which is enabled in Debian package via LSPP_PRIV=y.

what does newrole do? flush env block, change selinux context, re-invoke PAM session hooks? why does it do the env block flushing and re-invoking of PAM session hooks?

I'm pretty new to SELinux, but the idea is that the user account may have been assigned several SELinux roles, but only one of them is enabled when logged in. Then the user would switch the role with newrole much like sudo for switching UID to 0. For example, it's possible to divide uses of UID 0 to system_r for daemons, staff_r for logging in without system management rights, sysadm_r to enable system management rights, give separate roles for system log/compliance auditors, security policy managers etc.

The switch to the new SELinux role can be authenticated with PAM modules. I'm not sure what is the purpose of the env clearing (there's specific code to handle some traditional variables, so why not newer XDG_* also?) or why (or why not) there should (not) be a new PAM session. In comparison, you can invoke either su or su - and at least here it does not create a new session.