Use user keyring instead of session keyring

Currently fscrypt adds keys to session keyring (KEY_SPEC_SESSION_KEYRING). Applications started within systemd --user instance have their own session keyring which means they would have no access to encrypted directories. To fix this we need add keys to user keyring (KEY_SPEC_USER_KEYRING) instead.

You can test it by invoking systemd-run --user keyctl show,and check logs, the keyring is empty.

Using user keyring is recommended by systemd developers, see systemd/systemd#1299 (comment)

neithernut/pam_e4crypt#14
systemd/systemd#5715

[josephlr]

Thanks pointing out this unfortunate design choice by systemd. @tyhicks, any thought on how this could effect Ubuntu 17.10? I would have preferred to just use the session keyring, but I guess switching the keyring will be the path of least resistance.

[josephlr]

There's also the issue that their fix suggests linking the session keyring into the user keyring despite the fact that the linking is usually done in the other direction (user keyring linked into session keyring).

[tyhicks]

@josephlr it doesn't surprise me that the session keyring isn't going to work out. The session keyring has good intentions but it doesn't work very well in practice. That's why eCryptfs has always used the user session keyring.

The biggest downside is that it means that pam_fscrypt will have to clean up after itself and clear the keyring when no more sessions are active.

[josephlr]

@tyhicks would just removing all the keys in close_session that were added in open_session solve this?

[josephlr]

A scenario I can think of is when a user starts Session 1 which adds in keys, then starts Session 2 which will automatically have access to those keys. Session 2 will then lose access when Session 1 ends.

[tyhicks]

@josephlr yes but keep in mind that there may be multiple calls to open_session before the first call to close_session. That means that pam_fscrypt must have some sort of counter that only clears the keys in close_session once the counter goes to zero. pam_ecryptfs has this functionality but the implementation is not very clean.

There's also the issue that their fix suggests linking the session keyring into the user keyring despite the fact that the linking is usually done in the other direction (user keyring linked into session keyring).

As i read that was done this way only because pam_e4crypt supported only session keyring at that time. User keyring was linked to session keyring so it couldn't be linked back. That was the only reason for this dirty fix which you can safely ignore.

[derlaft]

The issue is closed, but what is the solution? I can not make it work for me for some reason

[josephlr]

@derlaft, what's the specific error you are getting? Can you run the problematic fscrypt command with --verbose or run pam_fscrypt.so with the debug flag?

[Redsandro]

Hi @josephlr, Google dropped me off here. I'm having the same sentiment: The issue is closed, but what is the solution?

$ sudo fscrypt setup
Create "/etc/fscrypt.conf"? [Y/n] 
Customizing passphrase hashing difficulty for this system...
Created global config file at "/etc/fscrypt.conf".

$ fscrypt --verbose encrypt enc/
fscrypt encrypt: user keyring not linked into session keyring

This is usually the result of a bad PAM configuration. Either correct the 
problem in your PAM stack, enable pam_keyinit.so, or run "keyctl link @u @s".

This is Linux Mint 19 Cinnamon with

• 4.15.0-50-generic #54-Ubuntu SMP
• fscrypt 0.2.2-0ubuntu2.1

[Maryse47]

@Redsandro Take a look at Set up PAM in the article.