linux/security/keys, branch v2.6.30

keys: Handle there being no fallback destination keyring for request_key()

2009-04-09T17:41:19Z

When request_key() is called, without there being any standard process keyrings on which to fall back if a destination keyring is not specified, an oops is liable to occur when construct_alloc_key() calls down_write() on dest_keyring's semaphore. Due to function inlining this may be seen as an oops in down_write() as called from request_key_and_link(). This situation crops up during boot, where request_key() is called from within the kernel (such as in CIFS mounts) where nobody is actually logged in, and so PAM has not had a chance to create a session keyring and user keyrings to act as the fallback. To fix this, make construct_alloc_key() not attempt to cache a key if there is no fallback key if no destination keyring is given specifically. Signed-off-by: David Howells Tested-by: Jeff Layton Signed-off-by: Linus Torvalds

keys: make procfiles per-user-namespace

2009-02-27T01:35:15Z

Restrict the /proc/keys and /proc/key-users output to keys belonging to the same user namespace as the reading task. We may want to make this more complicated - so that any keys in a user-namespace which is belongs to the reading task are also shown. But let's see if anyone wants that first. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

keys: skip keys from another user namespace

2009-02-27T01:35:12Z

When listing keys, do not return keys belonging to the same uid in another user namespace. Otherwise uid 500 in another user namespace will return keyrings called uid.500 for another user namespace. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

keys: consider user namespace in key_permission

2009-02-27T01:35:09Z

If a key is owned by another user namespace, then treat the key as though it is owned by both another uid and gid. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

keys: distinguish per-uid keys in different namespaces

2009-02-27T01:35:06Z

per-uid keys were looked by uid only. Use the user namespace to distinguish the same uid in different namespaces. This does not address key_permission. So a task can for instance try to join a keyring owned by the same uid in another namespace. That will be handled by a separate patch. Signed-off-by: Serge E. Hallyn Acked-by: David Howells Signed-off-by: James Morris

security: introduce missing kfree

2009-01-17T22:24:46Z

Plug this leak. Acked-by: David Howells Cc: James Morris Cc: Signed-off-by: Vegard Nossum Signed-off-by: Linus Torvalds

[CVE-2009-0029] System call wrappers part 28

2009-01-14T13:15:30Z

Signed-off-by: Heiko Carstens

[CVE-2009-0029] System call wrappers part 27

2009-01-14T13:15:29Z

Signed-off-by: Heiko Carstens

keys: fix sparse warning by adding __user annotation to cast

2008-12-31T23:32:44Z

Fix the following sparse warning: CC security/keys/key.o security/keys/keyctl.c:1297:10: warning: incorrect type in argument 2 (different address spaces) security/keys/keyctl.c:1297:10: expected char [noderef] *buffer security/keys/keyctl.c:1297:10: got char * which appears to be caused by lack of __user annotation to the cast of a syscall argument. Signed-off-by: James Morris Acked-by: David Howells

KEYS: Fix variable uninitialisation warnings

2008-12-29T03:24:43Z

Fix variable uninitialisation warnings introduced in: commit 8bbf4976b59fc9fc2861e79cab7beb3f6d647640 Author: David Howells Date: Fri Nov 14 10:39:14 2008 +1100 KEYS: Alter use of key instantiation link-to-keyring argument As: security/keys/keyctl.c: In function 'keyctl_negate_key': security/keys/keyctl.c:976: warning: 'dest_keyring' may be used uninitialized in this function security/keys/keyctl.c: In function 'keyctl_instantiate_key': security/keys/keyctl.c:898: warning: 'dest_keyring' may be used uninitialized in this function Some versions of gcc notice that get_instantiation_key() doesn't always set *_dest_keyring, but fail to observe that if this happens then *_dest_keyring will not be read by the caller. Reported-by: Linus Torvalds Signed-off-by: David Howells Signed-off-by: James Morris