Bug 11527 - Troubles with credentials in "session" kernel keyring
Summary: Troubles with credentials in "session" kernel keyring
Status: NEW
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 3.x
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: cifs QA contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-21 14:53 UTC by Mantas Mikulėnas (grawity)
Modified: 2020-07-16 00:12 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mantas Mikulėnas (grawity) 2015-09-21 14:53:28 UTC
Originally-reported-at: https://github.com/systemd/systemd/issues/1299

(Sigh. Let's play bug ping-pong.)

So I am mounting various cifs filesystems with -o multiuser, and storing the password in the kernel keyring (cifscreds &c).

But now certain parts of my X11 session are run via systemd, via a separate PAM stack, and thus have their own session keyring – independent from the other half of my X11 programs.

(Which, by the way, isn't exactly a new issue – urxvtd, tmux, emacs-daemon, screen would all have the same problem.)

As in the original bug report [linked above], I'm told that cifs.ko & cifs-utils should use the 'user' keyring instead of the 'session' one to avoid such problems:

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

Another way, I think, would be to "join" an existing named session keyring when logging in to X11 – I remember having seen this option in `keyctl session …`.