From: Michael S. <ms...@ya...> - 2010-02-09 16:39:18
|
On 2/9/2010 9:29 AM, Allen Pulsifer wrote: >> My project group at Yahoo! needs a way to use kernel keys >> (http://www.kernel.org/doc/Documentation/keys.txt) in our FUSE >> filesystems. We have come up with a couple ways to add >> support for this to FUSE, but I wanted to first reach out to >> this list to see if any work or discussion has already >> happened on this front. Any guidance would be appreciated. > > Why would FUSE need to support this? In other words, why can't you just use > it from your userspace file system, just like you would use any other > resource provided by the kernel, such as the system clock, the network > stack, etc. Why does FUSE need to support this in order for you to use it? The key retention service has both a user-mode and kernel-mode API, and it's designed around the assumption that filesystems will use the kernel-mode API. Suppose you have a filesystem that needs a user password for authorization against some network resource. The user could set the password as a key through some user-mode mechanism like keyctl(1). The key would be owned by the user, and no other users/groups would have the ability to read the key (not even root). When the user calls into a regular kernel filesystem, the filesystem can use the kernel API to read the user's key. This makes sense because the filesystem is acting on behalf of the user. In the case of a FUSE filesystem, the kernel API is never invoked. If the user-mode filesystem tries to read the key using the user-mode API, it will be denied access unless the user-mode FUSE process is running as the same user who made the filesystem request. Even if the FUSE filesystem is running as root (which would generally be a bad idea anyway), it can not use the user-mode key API to retrieve the contents of the key. This can be remedied by having generic support for keys in FUSE, along the same lines as other context information like pid, uid, gid, and secondary gids. Hopefully this gives an idea of the problem we're trying to solve. There are some other issues that I didn't go into, such as the difference between the various keyrings (thread, process, session, and so on). |