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
User bus breaks kernel "session" keyrings #1299
Comments
you are referring the kernel keyring here? I figure the lesson is that a concept of a "session" keyring is just crazy, and nobody should use them... |
Right, separating sessions from each other makes no sense security-wise on any usual workstation setup. Tools should switch to user-owned data instead of session-speficic data. The concept of sessions is not meant to carry any credentials or other data, it is only the user who owns everything. CIFS: |
I am tempted to simply close this issue here. I really think that keys should be shared among sessions of the same user, and hence should be attached to the user, and not any session... I think this is something to fix in samba, not in systemd... |
For the sake of searchers like me who stumble on this thread, I've written a patch that implements
for SMB passwords at https://www.spinics.net/lists/linux-cifs/msg25901.html It's incomplete since it only touches the userland so far, and since I don't know if the SMB maintainers have any interest in it. But it's out there. Maybe if you run into this like I did you can build on it to get a working solution. Or maybe I'll finish it one day, get my hands dirty in the kernel, but I've never done that and I'm not promising it. |
#1232 reminded me of an issue with the user bus model and kernel keyrings. It is similar to the problem with environment variables, but seems a bit harder to work around.
In short: Bus-activated apps cannot access credentials (e.g. SMB passwords) from the session keyring, as they belong to a different session.
In the past, gdm would first log me in, open a PAM session (invoking pam_keyinit to create a session keyring), and then launch the dbus-daemon instance for that session. All my programs, whether directly launched or bus-activated, would hold the same session keyring.
Now dbus-daemon is launched by
systemd --user
and holds a different session keyring (obtained through its own PAM stack). So any credentials seen by regular session programs are not seen by bus-activated programs, and vice versa.(For example, if I use pam_cifscreds to add my login password as a SMB password, it works fine from an xterm (spawned directly by WM), but not from gnome-terminal (bus-activated).
[I guess this is not exactly new, as tmux and urxvtd would also have the same problem... but these are explicit, whereas the user bus is set up without the user's knowledge.]
The text was updated successfully, but these errors were encountered: