[Bug 1754270] [NEW] systemd-user PAM configuration should initialize the keyring with pam_keyinit

[Trent Lloyd]

Public bug reported:

/etc/pam.d/systemd-user does not currently call pam_keyinit.so -- it's
possible this should instead be added to common-session-noninteractive
but I am not entirely sure about that - someone with more understanding
of the PAM modules would probably need to weigh in on that.  In any case
systemd-user itself should at least have it - as it has it's own special
PAMname for processes it launches.

This means that the keyring does not link to the user keyring as it
should, and will cause issues with programs needing a key from the
keyring.  In particular the use case that breaks for me is using
'fscrypt' and 'libpam-fscrypt' however anything making use of kernel
keyrings would be affected.

Something non-obvious about this, is that many desktop session processes
are started under 'systemd-user' instead of the 'session' - this
includes gnome-terminal-server which means any gnome-terminal shell runs
under this context.  If you start xterm instead of gnome-terminal, you
get a different keyring and this can cause confusion when debugging the
issue as some processes are in one state and the others are in another
including your primary debug tool gnome-terminal.  You can verify this
by running 'systemctl status $(pidof gnome-terminal)' and 'systemctl
status $(pidof xterm)' and note the different hierachy.

The change to add pam_keyinit.so was made upstream in December 2016:
https://github.com/systemd/systemd/commit/ab79099d1684457d040ee7c28b2012e8c1ea9a4f

Ubuntu should make the same change so that services needing a keyring
will work correctly in the desktop session, and the same keyring is used
for processes launched under both methods.  In my test I add the usual
pam_keyinit.so line after "pam_limits.so" and before "common-session-
noninteractive".  I am not sure if this is the most ideal location (but
it appears to work).


You can test the behavior by running "keyctl show @s" in both contexts

Working contexts:
- xterm
- SSH login

Broken contexts:
- gnome-terminal
- systemd-run --user keyctl show @s (then check output with journalctl --user --follow)


When the configuration is broken you will see this output:
lathiat at ubuntu:~/src/systemd$ keyctl show @s
Keyring
  59654779 --alswrv   1000  1000  keyring: _ses
   6806191 ----s-rv      0     0   \_ user: invocation_id

When the configuration is working, you will see a link to the user session instead:
lathiat at ubuntu:~/src/systemd$ keyctl show @s
Keyring
  59654779 --alswrv   1000  1000  keyring: _ses
   6806191 ----s-rv      0     0   \_ keyring: _uid.1000


As background, what is broken on my test setup with libpam-fscrypt?
gnome-terminal for example is unable to write any file in my encrypted /home which means that it cannot save preferences, so if you go into preferences and try to tick a checkbox it will immediately revert and an error is logged to the journal.  You can use the guide at https://github.com/google/fscrypt to setup such a system if you wish to fully test my case.  But you can simply verify the behavior as above.

Verified on bionic (its the only version with fscrypt) however this
issue extends back to at least xenial.

** Affects: systemd (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1754270

Title:
  systemd-user PAM configuration should initialize the keyring with
  pam_keyinit

Status in systemd package in Ubuntu:
  New

Bug description:
  /etc/pam.d/systemd-user does not currently call pam_keyinit.so -- it's
  possible this should instead be added to common-session-noninteractive
  but I am not entirely sure about that - someone with more
  understanding of the PAM modules would probably need to weigh in on
  that.  In any case systemd-user itself should at least have it - as it
  has it's own special PAMname for processes it launches.

  This means that the keyring does not link to the user keyring as it
  should, and will cause issues with programs needing a key from the
  keyring.  In particular the use case that breaks for me is using
  'fscrypt' and 'libpam-fscrypt' however anything making use of kernel
  keyrings would be affected.

  Something non-obvious about this, is that many desktop session
  processes are started under 'systemd-user' instead of the 'session' -
  this includes gnome-terminal-server which means any gnome-terminal
  shell runs under this context.  If you start xterm instead of gnome-
  terminal, you get a different keyring and this can cause confusion
  when debugging the issue as some processes are in one state and the
  others are in another including your primary debug tool gnome-
  terminal.  You can verify this by running 'systemctl status $(pidof
  gnome-terminal)' and 'systemctl status $(pidof xterm)' and note the
  different hierachy.

  The change to add pam_keyinit.so was made upstream in December 2016:
  https://github.com/systemd/systemd/commit/ab79099d1684457d040ee7c28b2012e8c1ea9a4f

  Ubuntu should make the same change so that services needing a keyring
  will work correctly in the desktop session, and the same keyring is
  used for processes launched under both methods.  In my test I add the
  usual pam_keyinit.so line after "pam_limits.so" and before "common-
  session-noninteractive".  I am not sure if this is the most ideal
  location (but it appears to work).

  
  You can test the behavior by running "keyctl show @s" in both contexts

  Working contexts:
  - xterm
  - SSH login

  Broken contexts:
  - gnome-terminal
  - systemd-run --user keyctl show @s (then check output with journalctl --user --follow)

  
  When the configuration is broken you will see this output:
  lathiat at ubuntu:~/src/systemd$ keyctl show @s
  Keyring
    59654779 --alswrv   1000  1000  keyring: _ses
     6806191 ----s-rv      0     0   \_ user: invocation_id

  When the configuration is working, you will see a link to the user session instead:
  lathiat at ubuntu:~/src/systemd$ keyctl show @s
  Keyring
    59654779 --alswrv   1000  1000  keyring: _ses
     6806191 ----s-rv      0     0   \_ keyring: _uid.1000

  
  As background, what is broken on my test setup with libpam-fscrypt?
  gnome-terminal for example is unable to write any file in my encrypted /home which means that it cannot save preferences, so if you go into preferences and try to tick a checkbox it will immediately revert and an error is logged to the journal.  You can use the guide at https://github.com/google/fscrypt to setup such a system if you wish to fully test my case.  But you can simply verify the behavior as above.

  Verified on bionic (its the only version with fscrypt) however this
  issue extends back to at least xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754270/+subscriptions