systemd --user instance doesn't inherit user's session keyring

[seebaclo]

Systemd --user instance which is started through pam_systemd.so module doesn't use user's session keyring so all user services don't have access to encrypted files. I already reported it upstream but it looks like a design choice which breaks many types of authentication. I don't know if pam_e4crypt could help with this linking keys from user keyring to systemd-user keyring or add keys to system-user keyring directly.

[neithernut]

We use the session keyring. That keyring is inherited by child processes. Unlike the user and user session keyrings, it is not bound to a UID and can not be used by arbitrary sessions of the same user. As far as I remember, using the session keyring was the only possibility to get the module to work properly (keys in other keyrings would be ignored), but I could well be mistaken. At least the e4crypt tool uses the session key, as is apparent from your keyctl output.

It could well be that systemd-run initializes its own session keyring and hence doesn't propagate your keys to services. Honestly, I don't care about systemd and I try to stay as far away as possible from it.

This module will probably be of no use for solving this problem. You could try to link the keys to a user keyring using keyctl link and then link them back to the service's session from there.

TL;DR: his is clearly outside the scope of this module. Anyways, good luck.

[seebaclo]

Just quick recap after I found solution:

pam_keyinit module automatically links user keyring @u to session keyring @s so I couldn't link back @s to u@ due to recursion.

User keyring @u is automatically linked to user session keyring @us. I could link from @s to @us manually after login but it was too late for some services to get access. On the other hand linking it early didn't work (services didn't used this keyring then).

So, finally I had to disable pam_keyinit module from system-login pam section and link session keyring @s to user keyring @u. I don't know if there are any disadvantages of this as I don't add any keys to my user keyring anyway and Archlinux even didn't include this module by default. It's still included in systemd-user pam section and i believe it's enough.

[seebaclo]

Hm, I just thinked about it:

e4crypt tool uses session keyring by default but it has -k option which provide ability to choose keyring manually i.e e4crypt add_key -k @u.

You wrote that you can't use other keyrings within pam_e4crypt - wasn't pam_keyinit the reason here as it occurred in my case? If yes whe can move pam_keyinit module below pam_e4crypt in system-login pam section and add key to user's keyring which will be automatically linked to session's keyring by pam_keyinit later.

So we end up with keys in both user and session keyrings which should be easier to manage.

[okias]

@seebaclo could you publish your service file? I'm trying to do something similiar and this would really help me.

[ralcantaraperez]

I don't know if it can help you but I'm using this file to force systemd to inherit keys (in Ubuntu /etc/systemd/system/service_name.service.d/customexec.conf):

[Service]
KeyringMode=shared

[neithernut]

Thanks for the hint. Maybe I should add this to the README.