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@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.
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
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
