Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: In-kernel Authentication Tokens (PAGs) | Date | Tue, 15 Jun 2004 19:48:41 -0400 |
| |
On Jun 15, 2004, at 18:07, Chris Wright wrote: > * Kyle Moffett (mrmacman_g4@mac.com) wrote: >> One thing that I would very much like to have is the ability to create >> a new >> shell with a new keyring, such that I can still see and use the old >> keyring, >> but I can create new keys without modifying the old keyring, even to >> the >> extent of masking out keys in the old keyring without modifying them >> for >> other processes. From my brief glance at your patch, that's not a >> feature you have implemented. > Sounds like a CLONE_KEYRING flag?
I think the two concepts are unrelated. You should not be required to create a new thread/process/task in order to give yourself a separate key-ring, and it would be plain stupid to have one mode of the clone() syscall that doesn't create a new task but instead changes key-rings Take Apache and suexec PHP for example: it would be very useful to be able to have a key-ring owned by the root user that contains the AFS keys Apache uses to access files. Then when it runs a suexec PHP script, it adds a new key-ring owned by "someuser" to the process (without doing a clone()). It does a seteuid("someuser"), then proceeds with the PHP code. That gives the user's PHP its own key-ring context, and protects the parent's key-ring. When done it removes "someuser"'s keys and does seteuid(0).
Cheers, Kyle Moffett
- 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/
| |