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@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-maintain...@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?
signature.asc
Description: OpenPGP digital signature