Found a Debian bug about the same issue but with AFS instead of fscrypt: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846377
** Bug watch added: Debian Bug tracker #846377 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846377 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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@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@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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
