Bug#846377: discovered likely cause of this issue

[Michael Biebl]

Thanks Trent for further investigating this.

Dirk, can you confirm that adding pam_keyinit.so to
/etc/pam.d/systemd-user solves the problem for you as well?

Am 08.03.2018 um 09:47 schrieb 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
> 
> _______________________________________________
> Pkg-systemd-maintainers mailing list
> Pkg-systemd-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180308/ec493d8d/attachment-0002.sig>