lkml.org 
[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH] keys & keyring management: key filesystem
    Date

    Here's a preliminary look a patch I've concocted to make keys accessible
    through yet another filesystem (TM). At the moment, it only gives a read-only
    view onto the keys in the system.

    The patch can be found at:

    http://people.redhat.com/~dhowells/keys/keyfs-268rc2.diff.bz2

    It requires the keys-268rc2-6.diff.bz2 patch to supply the basic key services.


    Currently, it makes a filesystem that looks like:

    /keyfs/
    thread [symlink to process's thread key]
    process [symlink to process's process key]
    session [symlink to process's session key]
    user [symlink to user key for process's UID]
    user-session [symlink to def session key for process's UID]
    <key>/ [directory representing a key]
    type [file holding key type as a string]
    description [file holding key description as a string]
    expiry [file holding key expiry time as a decimal string]
    perm [file holding key access mask as an octal string]
    payload [file permitting reading/writing of key's payload data]
    <key>/ [directory representing a keyring]
    type [file holding key type as a string]
    description [file holding key description as a string]
    expiry [file holding key expiry time as a decimal string]
    perm [file holding key access mask as an octal string]
    keyring/ [directory representing a keyring's contents]
    <key> [symlink to linked keys]


    I've encountered some problems:

    (1) readdir() on the root directory has to run in O(N^2) time because the key
    tree lock is a spinlock and the filldir call is permitted to sleep.

    I could solve this by making the spinlock into a semaphore, and just
    read-locking it for the duration of the whole readdir call. But this has
    other problems: it'll exclude any key changes for the duration,
    especially if calling filldir causes it to swap a lot.

    I don't think global enumeration is necessarily a good idea. /proc/keys
    is a debugging interface, to be made root readable only at some point. I
    don't think you should be able to _see_ any keys you don't have any
    rights to. Do people disagree with that?

    (2) It weakens security to some extent: it makes keys more accessible, more
    visible.

    I could, perhaps, deal with this by filtering the keys in readdir() and
    lookup() on the root directory.

    (3) The key permissions mask doesn't map easily to the usual RWX bits on a
    file with their strictly VFS meaning. Whilst on a key I'm using the 'X'
    bits to indicate search permission, that can't directly control execute
    permission on the key directory.

    (4) Accessing keys this way requires more syscall invocations, more locks to
    be dealt with, etc. than the syscall approach. It's a lot less efficient,
    particularly when it comes to producing a list of the same data seen in
    /proc/keys.

    (5) The kernel filesystem side of this is already much bigger than the
    syscall/prctl approach, even when it's read-only.

    (6) d_revalidate and getattr need to be supplied for any file or directory
    that relates to a particular key to pick up UID/GID/permissions changes.

    This is difficult to avoid. Each key has to be represented by several
    inodes, and they all need to be kept in sync.


    I still haven't seen any really good arguments why I should get rid of all the
    syscalls/prctls and drive it from userspace _entirely_ through a keyfs. We
    seem to be going a little overboard with the "everything must be a filesystem
    approach".

    I could perhaps make all the key syscalls ioctls on a control file placed in
    the root directory:-)

    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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.042 / U:328.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site