[RFC][PATCH0/5] Keys patches

[David Howells]

Hi Linus, James,

Here are some fixes for the new keyring stuff.  They break down into three
sets:

 (1) A patch to error handling in the big_key type for huge payloads.  If the
     payload is larger than the "low limit" and the backing store allocation
     fails, then big_key_instantiate() doesn't clear the payload pointers in
     the key, assuming them to have been previously cleared - but only one of
     them is.

     Unfortunately, the garbage collector still calls big_key_destroy() when
     sees one of the pointers with a weird value in it (and not NULL) which it
     then tries to clean up.

 (2) Three patches to fix the keyring type:

     (a) A patch to fix the hash function to correctly divide keyrings off from
     keys in the topology of the tree inside the associative array.  This is
     only a problem if searching through nested keyrings - and only if the hash
     function incorrectly puts the a keyring outside of the 0 branch of the
     root node.

     (b) A patch to fix keyrings' use of the associative array.  The
     __key_link_begin() function initially passes a NULL key pointer to
     assoc_array_insert() on the basis that it's holding a place in the tree
     whilst it does more allocation and stuff.

     This is only a problem when a node contains 16 keys that match at that
     level and we want to add an also matching 17th.  This should easily be
     manufactured with a keyring full of keyrings (without chucking any other
     sort of key into the mix) - except for (a) above which makes it on average
     adding the 65th keyring.

     (c) A patch to fix searching down through nested keyrings, where any
     keyring in the set has more than 16 keyrings and none of the first
     keyrings we look through has a match (before the tree iteration needs to
     step to a more distal node).

 (3) A patch to fix the big_key type's use of a shmem file as its backing store
     causing audit messages and LSM check failures.  This is done by setting
     S_PRIVATE on the file to avoid LSM checks on the file (access to the shmem
     file goes through the keyctl() interface and so is gated by the LSM that
     way).

     This isn't normally a problem if a key is used by the context that
     generated it - and it's currently only used by libkrb5.

David
---
David Howells (4):
      KEYS: Pre-clear struct key on allocation
      KEYS: Fix the keyring hash function
      KEYS: Fix multiple key add into associative array
      KEYS: Fix searching of nested keyrings

Eric Paris (1):
      security: shmem: implement kernel private shmem inodes


 Documentation/assoc_array.txt |    6 +++---
 include/linux/assoc_array.h   |    6 +++---
 include/linux/shmem_fs.h      |    2 ++
 lib/assoc_array.c             |    4 ++--
 mm/shmem.c                    |   36 +++++++++++++++++++++++++++++-------
 security/keys/big_key.c       |    2 +-
 security/keys/key.c           |    8 +-------
 security/keys/keyring.c       |   17 ++++++++---------
 8 files changed, 49 insertions(+), 32 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/