From: David Howells <dhowells@redhat.com>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Blair Strang <bls@asterisk.co.nz>,
Linus Torvalds <torvalds@osdl.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: In-kernel Authentication Tokens (PAGs)
Date: Wed, 16 Jun 2004 15:22:21 +0100 [thread overview]
Message-ID: <9960.1087395741@redhat.com> (raw)
In-Reply-To: <3943FF92-BEFE-11D8-95EB-000393ACC76E@mac.com>
> 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
next prev parent reply other threads:[~2004-06-16 14:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-12 2:37 In-kernel Authentication Tokens (PAGs) Kyle Moffett
2004-06-12 3:13 ` Andy Lutomirski
2004-06-12 4:57 ` Kyle Moffett
2004-06-12 5:34 ` Andy Lutomirski
2004-06-12 12:51 ` Kyle Moffett
2004-06-12 15:37 ` Andy Lutomirski
2004-06-12 17:15 ` Kyle Moffett
2004-06-12 3:15 ` Chris Wright
2004-06-12 4:48 ` Kyle Moffett
2004-06-12 20:53 ` Chris Wright
2004-06-12 21:15 ` Kyle Moffett
2004-06-12 21:44 ` Chris Wright
2004-06-12 21:58 ` Kyle Moffett
2004-06-12 22:51 ` Chris Wright
2004-06-12 23:40 ` Kyle Moffett
2004-06-12 22:51 ` Trond Myklebust
2004-06-12 23:33 ` Kyle Moffett
2004-06-12 23:58 ` Trond Myklebust
2004-06-13 0:23 ` Kyle Moffett
2004-06-15 6:38 ` Blair Strang
2004-06-15 7:03 ` Trond Myklebust
2004-06-15 9:36 ` David Howells
2004-06-15 19:00 ` Kyle Moffett
2004-06-15 22:07 ` Chris Wright
2004-06-15 23:48 ` Kyle Moffett
2004-06-16 0:01 ` Chris Wright
2004-06-16 0:06 ` Kyle Moffett
2004-06-16 14:22 ` David Howells [this message]
2004-06-15 22:29 ` Chris Wright
2004-06-16 14:37 ` David Howells
2004-06-15 23:59 ` Kyle Moffett
2004-06-16 14:49 ` David Howells
2004-06-17 1:13 ` Kyle Moffett
2004-06-17 11:48 ` David Howells
2004-06-17 19:06 ` Kyle Moffett
2004-06-23 12:29 ` David Howells
2004-06-23 21:03 ` Kyle Moffett
2004-06-29 17:07 ` Kyle Moffett
2004-07-07 18:54 ` John Bucy
2004-07-08 1:29 ` Kyle Moffett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9960.1087395741@redhat.com \
--to=dhowells@redhat.com \
--cc=bls@asterisk.co.nz \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.