Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] implement in-kernel keys & keyring management [try #2] | Date | Tue, 10 Aug 2004 19:49:32 +0100 |
| |
James Morris <jmorris@redhat.com> wrote: > You write and then read, like the transaction based IO methods in > selinuxfs (TA_write, TA_read).
Hmmm... You need to consider the fact that you need three or four pieces of information to create a key: type, description, payload (if there's a payload - there may not be) and destination keyring ID; and the payload is a binary blob of data.
I could say that you must do this as a single write of a buffer containing three NUL terminated strings, one after the other, followed, if present, by a binary blob...
Maybe I should say you have to use an ioctl()... :-)
> > Maintaining access controls would be fun though... How does the kernel then > > distinguish between a read and a search? > > I guess you'd use normal filsystem access controls instead of storing them > with the keys themselves. i.e. keyrings are directories, and keys are > files (or directories with files including metadata and key data). Then > xattrs could be used to integrate with things like SELinux. A user could > then use chmod to specify whether a kerying can be searched, for example.
Keyring permissions don't map exactly to file or directory attributes. If you, for instance, place the key permissions mask on the directory representing the key/keyring, then search permission controls whether you can access any file in that directory, which isn't practical.
I think I'd have to keep the key search mask in a separate file under that key directory, and have you read or write to it rather than using chmod.
chmod() isn't an option, really: key permissions don't really map well to file permissions. I suppose also key permissions really ought to have more than RWX permission can handle:
{ read, write, search, subscribe } x { UID, GID, Other }
Currently, I permit subscription (link) to any key for which you have either read or execute permission.
I also don't really want you to be able to _see_ any key for which you don't have any permission, so readdir() on /keyfs/ should not report any directory corresponding to a file you can't see. I should implement this on my /proc/keys too.
> The main point is that a filesystem API provides several useful framework > components by default:access control, creat/open/read/write etc. syscalls, > hierarchical structure and xattrs. Using a filesystem API means not > inventing yet another class of API.
I think you're wrong:
(1) Making a service like this accessible through a filesystem is as much creating a new class of API, as is creating new prctl() functions or new syscalls. It's just an API built on read(), write(), etc. rather than being on the syscall interface directly.
(2) A filesystem API is _way_ less efficient, though that probably isn't too much of a problem in this case. You have to do several VFS syscalls to achieve many things you could just do with a single real syscall.
(3) Hierarchy? So what? You can't really represent a set of nested keyrings as a set of nested directories since keys can have multiple parents. Besides, keys don't make a single tree.
You'd have to represent links in a keyring as symlinks, but when creating them, how do you interpret the argument given to symlink()?
(4) I suspect a filesystem API will be a lot heavier on code and memory.
(5) Text parsers are required in a number of cases.
(6) Using a filesystem API throws more locks into the works.
The downsides of adding a number of new syscalls are:
(1) glibc, uclibc, etc
(2) 32->64 bit syscall translation
(3) Adding the new syscalls to all archs
However, using prctl(), I just about get all three for free:-)
But are they really greater than the downsides of trying to do it through the filesystem API to which doesn't really map, and which must be abused?
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/
| |