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

[Dan Streetman]

please reopen if this is still an issue

** Changed in: systemd (Ubuntu)
       Status: Confirmed => Invalid

-- 
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:
  Invalid

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