Bug#846377: discovered likely cause of this issue

[Dirk Heinrichs]

Am 08.03.2018 um 12:11 schrieb Michael Biebl:

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

No, it doesn't. After adding it and logging out and back in I still get
this:

% keyctl show @s
Keyring
 918482795 ---lswrv  0 0  keyring: _ses.20321
  92578899 s--v  0 0   \_ afs_pag: _pag

and, for example:

% systemctl --user enable syncthing
Failed to enable unit: Access denied

However, I got the hint in the related systemd issue
,
that it might be possible to solve this in AFS, by using the user
keyring instead of the session keyring. Will start a discussion on this
on openafs-info soon...

Bye...

    Dirk

-- 
Dirk Heinrichs 
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de



signature.asc
Description: OpenPGP digital signature

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@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

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@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