Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] implement in-kernel keys & keyring management | Date | Sat, 07 Aug 2004 18:45:06 +0100 |
| |
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 this in the "search path" for keyring search.
However, it has become obvious that it's necessary to be able to exclude the user keyring from the search path under certain circumstances, so I thought why not add it to the session key, so that it is accessible via keyring nesting.
However, I think it's still necessary to show some separation between the session and the user keyrings, and unless PAM or something is made use of, you won't get that if each process uses the user keyring as its session by default.
It also allows me to add a facility by which a process can duplicate its session keyring and subscribe to the new one instead, whilst retaining a link to 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-session keyring sets the UID to something non-zero. Execution of a SUID binary does not 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()?).
(*) Have an init-specific session keyring as well.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |