29 Apr, 2008

2 commits

  • Make the keyring quotas controllable through /proc/sys files:

    (*) /proc/sys/kernel/keys/root_maxkeys
    /proc/sys/kernel/keys/root_maxbytes

    Maximum number of keys that root may have and the maximum total number of
    bytes of data that root may have stored in those keys.

    (*) /proc/sys/kernel/keys/maxkeys
    /proc/sys/kernel/keys/maxbytes

    Maximum number of keys that each non-root user may have and the maximum
    total number of bytes of data that each of those users may have stored in
    their keys.

    Also increase the quotas as a number of people have been complaining that it's
    not big enough. I'm not sure that it's big enough now either, but on the
    other hand, it can now be set in /etc/sysctl.conf.

    Signed-off-by: David Howells
    Cc:
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • Signed-off-by: Alexey Dobriyan
    Cc: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

25 Jan, 2008

1 commit


13 Feb, 2007

1 commit

  • Many struct file_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

27 Jun, 2006

1 commit


29 Sep, 2005

1 commit

  • The attached patch adds extra permission grants to keys for the possessor of a
    key in addition to the owner, group and other permissions bits. This makes
    SUID binaries easier to support without going as far as labelling keys and key
    targets using the LSM facilities.

    This patch adds a second "pointer type" to key structures (struct key_ref *)
    that can have the bottom bit of the address set to indicate the possession of
    a key. This is propagated through searches from the keyring to the discovered
    key. It has been made a separate type so that the compiler can spot attempts
    to dereference a potentially incorrect pointer.

    The "possession" attribute can't be attached to a key structure directly as
    it's not an intrinsic property of a key.

    Pointers to keys have been replaced with struct key_ref *'s wherever
    possession information needs to be passed through.

    This does assume that the bottom bit of the pointer will always be zero on
    return from kmem_cache_alloc().

    The key reference type has been made into a typedef so that at least it can be
    located in the sources, even though it's basically a pointer to an undefined
    type. I've also renamed the accessor functions to be more useful, and all
    reference variables should now end in "_ref".

    Signed-Off-By: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

24 Jun, 2005

1 commit

  • The attached patch changes the key implementation in a number of ways:

    (1) It removes the spinlock from the key structure.

    (2) The key flags are now accessed using atomic bitops instead of
    write-locking the key spinlock and using C bitwise operators.

    The three instantiation flags are dealt with with the construction
    semaphore held during the request_key/instantiate/negate sequence, thus
    rendering the spinlock superfluous.

    The key flags are also now bit numbers not bit masks.

    (3) The key payload is now accessed using RCU. This permits the recursive
    keyring search algorithm to be simplified greatly since no locks need be
    taken other than the usual RCU preemption disablement. Searching now does
    not require any locks or semaphores to be held; merely that the starting
    keyring be pinned.

    (4) The keyring payload now includes an RCU head so that it can be disposed
    of by call_rcu(). This requires that the payload be copied on unlink to
    prevent introducing races in copy-down vs search-up.

    (5) The user key payload is now a structure with the data following it. It
    includes an RCU head like the keyring payload and for the same reason. It
    also contains a data length because the data length in the key may be
    changed on another CPU whilst an RCU protected read is in progress on the
    payload. This would then see the supposed RCU payload and the on-key data
    length getting out of sync.

    I'm tempted to drop the key's datalen entirely, except that it's used in
    conjunction with quota management and so is a little tricky to get rid
    of.

    (6) Update the keys documentation.

    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds