Bug#846377: discovered likely cause of this issue

[Trent Lloyd]

I believe I know the cause for this issue.  I ran into the same issue 
when trying to use fscrypt to setup ext4 encryption for /home on Ubuntu 
Bionic

/etc/pam.d/systemd-user does not currently call pam_keyinit.so. 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.

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

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.

This sounds very similar to the behavior described by the AFS users.   A 
quick google suggests as I would expect that AFS is in fact using the 
kernel keyring.

I detailed most of this same info in my bug for Ubuntu here, including 
for reference:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754270

Regards,
Trent