Trond Myklebust <trond.myklebust@fys.uio.no> wrote> > - Two std keyrings per user: per-user and default-user-session> > So what *is* the reason for the "per-user" and "default-user-session"> keys?

Well, Linus wants a user keyring. Originally I was going to just include thisin the "search path" for keyring search.

However, it has become obvious that it's necessary to be able to exclude theuser keyring from the search path under certain circumstances, so I thoughtwhy not add it to the session key, so that it is accessible via keyringnesting.

However, I think it's still necessary to show some separation between thesession and the user keyrings, and unless PAM or something is made use of, youwon't get that if each process uses the user keyring as its session bydefault.

It also allows me to add a facility by which a process can duplicate itssession keyring and subscribe to the new one instead, whilst retaining a linkto the real user keyring.

Of course, this is open to negotiation. I'm not entirely convinced I need it,but it seemed right at the time.

> In a strong authentication model, a setuid process should not normally> find itself automatically authenticated to a new set of keys.

This only happens when a process subscribed to the root default-user-sessionkeyring sets the UID to something non-zero. Execution of a SUID binary doesnot change the session keyring.

The idea was that non-root users will probably want their own session keyring,not root's.

I can think of several other ways of dealing with this:

(*) Let userspace (PAM) determine the session.

(*) Start with no session keyring set on any process, and only attach a process to the default-user-session when someone tries to access their session keyring if there isn't one set, or when a setuid() is performed (or maybe setsid()?).