-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use user keyring instead of session keyring #34
Comments
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. |
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). |
@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. |
@tyhicks would just removing all the keys in |
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. |
@josephlr yes but keep in mind that there may be multiple calls to |
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. |
The issue is closed, but what is the solution? I can not make it work for me for some reason |
@derlaft, what's the specific error you are getting? Can you run the problematic |
Hi @josephlr, Google dropped me off here. I'm having the same sentiment: The issue is closed, but what is the solution?
This is Linux Mint 19 Cinnamon with
|
@Redsandro Take a look at Set up PAM in the article. |
Thank you @Maryse47. It appears to work fine, even for an encrypted home, on a test machine. Will this persist through relevant Ubuntu 18.04 LTS updates? Or is it plausible that certain updates will remove the PAM fix and cause /home to become unreadable? |
It will persist. That fix is quite well integrated with ubuntu pam config and it's very unlikely that something will break it. |
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
The text was updated successfully, but these errors were encountered: