linux/security/keys/request_key.c, branch v3.4.22

usermodehelper: kill umh_wait, renumber UMH_* constants

2012-03-23T23:58:41Z

No functional changes. It is not sane to use UMH_KILLABLE with enum umh_wait, but obviously we do not want another argument in call_usermodehelper_* helpers. Kill this enum, use the plain int. Signed-off-by: Oleg Nesterov Cc: Tetsuo Handa Cc: Rusty Russell Cc: Tejun Heo Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

KEYS: Fix error handling in construct_key_and_link()

2011-06-22T01:31:45Z

Fix error handling in construct_key_and_link(). If construct_alloc_key() returns an error, it shouldn't pass out through the normal path as the key_serial() called by the kleave() statement will oops when it gets an error code in the pointer: BUG: unable to handle kernel paging request at ffffffffffffff84 IP: [] request_key_and_link+0x4d7/0x52f .. Call Trace: [] request_key+0x41/0x75 [] cifs_get_spnego_key+0x206/0x226 [cifs] [] CIFS_SessSetup+0x511/0x1234 [cifs] [] cifs_setup_session+0x90/0x1ae [cifs] [] cifs_get_smb_ses+0x34b/0x40f [cifs] [] cifs_mount+0x13f/0x504 [cifs] [] cifs_do_mount+0xc4/0x672 [cifs] [] mount_fs+0x69/0x155 [] vfs_kern_mount+0x63/0xa0 [] do_kern_mount+0x4d/0xdf [] do_mount+0x63c/0x69f [] sys_mount+0x88/0xc2 [] system_call_fastpath+0x16/0x1b Signed-off-by: David Howells Acked-by: Jeff Layton Signed-off-by: Linus Torvalds

KEYS/DNS: Fix ____call_usermodehelper() to not lose the session keyring

2011-06-17T16:40:48Z

____call_usermodehelper() now erases any credentials set by the subprocess_inf::init() function. The problem is that commit 17f60a7da150 ("capabilites: allow the application of capability limits to usermode helpers") creates and commits new credentials with prepare_kernel_cred() after the call to the init() function. This wipes all keyrings after umh_keys_init() is called. The best way to deal with this is to put the init() call just prior to the commit_creds() call, and pass the cred pointer to init(). That means that umh_keys_init() and suchlike can modify the credentials _before_ they are published and potentially in use by the rest of the system. This prevents request_key() from working as it is prevented from passing the session keyring it set up with the authorisation token to /sbin/request-key, and so the latter can't assume the authority to instantiate the key. This causes the in-kernel DNS resolver to fail with ENOKEY unconditionally. Signed-off-by: David Howells Acked-by: Eric Paris Tested-by: Jeff Layton Signed-off-by: Linus Torvalds

Merge branch 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs

2011-05-27T17:25:02Z

* 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs: Create Documentation/security/, move LSM-, credentials-, and keys-related files from Documentation/ to Documentation/security/, add Documentation/security/00-INDEX, and update all occurrences of Documentation/ to Documentation/security/.

Create Documentation/security/,

2011-05-19T22:59:38Z

move LSM-, credentials-, and keys-related files from Documentation/ to Documentation/security/, add Documentation/security/00-INDEX, and update all occurrences of Documentation/ to Documentation/security/.

KEYS: Improve /proc/keys

2011-03-17T00:59:32Z

Improve /proc/keys by: (1) Don't attempt to summarise the payload of a negated key. It won't have one. To this end, a helper function - key_is_instantiated() has been added that allows the caller to find out whether the key is positively instantiated (as opposed to being uninstantiated or negatively instantiated). (2) Do show keys that are negative, expired or revoked rather than hiding them. This requires an override flag (no_state_check) to be passed to search_my_process_keyrings() and keyring_search_aux() to suppress this check. Without this, keys that are possessed by the caller, but only grant permissions to the caller if possessed are skipped as the possession check fails. Keys that are visible due to user, group or other checks are visible with or without this patch. Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: Add a new keyctl op to reject a key with a specified error code

2011-03-08T00:17:18Z

Add a new keyctl op to reject a key with a specified error code. This works much the same as negating a key, and so keyctl_negate_key() is made a special case of keyctl_reject_key(). The difference is that keyctl_negate_key() selects ENOKEY as the error to be reported. Typically the key would be rejected with EKEYEXPIRED, EKEYREVOKED or EKEYREJECTED, but this is not mandatory. Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: Fix __key_link_end() quota fixup on error

2011-01-25T22:58:20Z

Fix __key_link_end()'s attempt to fix up the quota if an error occurs. There are two erroneous cases: Firstly, we always decrease the quota if the preallocated replacement keyring needs cleaning up, irrespective of whether or not we should (we may have replaced a pointer rather than adding another pointer). Secondly, we never clean up the quota if we added a pointer without the keyring storage being extended (we allocate multiple pointers at a time, even if we're not going to use them all immediately). We handle this by setting the bottom bit of the preallocation pointer in __key_link_begin() to indicate that the quota needs fixing up, which is then passed to __key_link() (which clears the whole thing) and __key_link_end(). Signed-off-by: David Howells Signed-off-by: Linus Torvalds

KEYS: Fix up comments in key management code

2011-01-21T22:59:30Z

Fix up comments in the key management code. No functional changes. Signed-off-by: David Howells Signed-off-by: Linus Torvalds

KEYS: Don't call up_write() if __key_link_begin() returns an error

2010-12-23T23:31:48Z

In construct_alloc_key(), up_write() is called in the error path if __key_link_begin() fails, but this is incorrect as __key_link_begin() only returns with the nominated keyring locked if it returns successfully. Without this patch, you might see the following in dmesg: ===================================== [ BUG: bad unlock balance detected! ] ------------------------------------- mount.cifs/5769 is trying to release lock (&key->sem) at: [] request_key_and_link+0x263/0x3fc but there are no more locks to release! other info that might help us debug this: 3 locks held by mount.cifs/5769: #0: (&type->s_umount_key#41/1){+.+.+.}, at: [] sget+0x278/0x3e7 #1: (&ret_buf->session_mutex){+.+.+.}, at: [] cifs_get_smb_ses+0x35a/0x443 [cifs] #2: (root_key_user.cons_lock){+.+.+.}, at: [] request_key_and_link+0x10a/0x3fc stack backtrace: Pid: 5769, comm: mount.cifs Not tainted 2.6.37-rc6+ #1 Call Trace: [] ? request_key_and_link+0x263/0x3fc [] print_unlock_inbalance_bug+0xca/0xd5 [] lock_release_non_nested+0xc1/0x263 [] ? request_key_and_link+0x263/0x3fc [] ? request_key_and_link+0x263/0x3fc [] lock_release+0x17d/0x1a4 [] up_write+0x23/0x3b [] request_key_and_link+0x263/0x3fc [] ? cifs_get_spnego_key+0x61/0x21f [cifs] [] request_key+0x41/0x74 [] cifs_get_spnego_key+0x200/0x21f [cifs] [] CIFS_SessSetup+0x55d/0x1273 [cifs] [] cifs_setup_session+0x90/0x1ae [cifs] [] cifs_get_smb_ses+0x37f/0x443 [cifs] [] cifs_mount+0x1aa1/0x23f3 [cifs] [] ? alloc_debug_processing+0xdb/0x120 [] ? cifs_get_spnego_key+0x1ef/0x21f [cifs] [] cifs_do_mount+0x165/0x2b3 [cifs] [] vfs_kern_mount+0xaf/0x1dc [] do_kern_mount+0x4d/0xef [] do_mount+0x6f4/0x733 [] sys_mount+0x88/0xc2 [] system_call_fastpath+0x16/0x1b Reported-by: Jeff Layton Signed-off-by: David Howells Reviewed-and-Tested-by: Jeff Layton Signed-off-by: Linus Torvalds