linux.git/security/keys/request_key.c, branch v3.0-rc2

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

2011-05-27T17:25:02+00:00

* '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:38+00:00

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:32+00:00

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:18+00:00

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:20+00:00

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:30+00:00

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:48+00:00

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

KEYS: request_key() should return -ENOKEY if the constructed key is negative

2010-08-06T16:17:02+00:00

request_key() should return -ENOKEY if the key it constructs has been
negatively instantiated.

Without this, request_key() can return an unusable key to its caller,
and if the caller then does key_validate() that won't catch the problem.

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

KEYS: Reinstate lost passing of process keyring ID in call_sbin_request_key()

2010-08-02T05:34:56+00:00

In commit bb952bb98a7e479262c7eb25d5592545a3af147d there was the accidental
deletion of a statement from call_sbin_request_key() to render the process
keyring ID to a text string so that it can be passed to /sbin/request-key.

With gcc 4.6.0 this causes the following warning:

  CC      security/keys/request_key.o
security/keys/request_key.c: In function 'call_sbin_request_key':
security/keys/request_key.c:102:15: warning: variable 'prkey' set but not used

This patch reinstates that statement.

Without this statement, /sbin/request-key will get some random rubbish from the
stack as that parameter.

Signed-off-by: Justin P. Mattock 
Signed-off-by: David Howells 
Signed-off-by: James Morris

umh: creds: convert call_usermodehelper_keys() to use subprocess_info->init()

2010-05-27T16:12:45+00:00

call_usermodehelper_keys() uses call_usermodehelper_setkeys() to change
subprocess_info->cred in advance.  Now that we have info->init() we can
change this code to set tgcred->session_keyring in context of execing
kernel thread.

Note: since currently call_usermodehelper_keys() is never called with
UMH_NO_WAIT, call_usermodehelper_keys()->key_get() and umh_keys_cleanup()
are not really needed, we could rely on install_session_keyring_to_cred()
which does key_get() on success.

Signed-off-by: Oleg Nesterov 
Acked-by: Neil Horman 
Acked-by: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds