Messages in this thread | | | From | David Howells <> | Subject | Re: In-kernel Authentication Tokens (PAGs) | Date | Wed, 16 Jun 2004 15:22:21 +0100 |
| |
> 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.
Hmmm... What exactly are you wanting to do? Each task theoretically subscribes to five keyrings (the group one isn't yet there) in this model; three of which are transferred across a fork, and four across CLONE_THREAD.
The five keyrings are:
- Group (associated with primary GID) - User (associated with UID) - Session (voluntarily discarded) - Process (shared between threads in a process) - Thread (one per thread)
> I would also like the ability to mark a key as unreadable except by kernel > threads or processes with CAP_KEYRING.
What do you mean by "unreadable"?
Currently, userspace can't see the data attached to a key. It can only see the description, and only then through /proc/keys.
> If I can pass key "handles" of some sort over UNIX sockets, then I can also > pass an unreadable key to a daemon process which uses it to access my files > until I revoke the key.
I can see what you're getting at.
I think I need to create some more operations:
(*) Retire/Revoke key
(*) Add key to another keyring
(*) Remove key from keyring
(*) List keyring
(*) Describe key
(*) Read key (if not protected)
(*) Create keyring
I have pondered representing keyspace with some sort of filesystem interface (using vfs ops to represent the operations), but that could require hardlinked directories (keyrings) to pull off - either that or symlinks.
Also, there's the problem of security on the operations themselves. How do you determine what a process is allowed to do?
Either I should only allow access to keys and keyrings to which a process is subscribed, or I should attach UID/GID/MASK values to every key and keyring.
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/
| |