| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | /* internal.h: authentication token and access key management internal defs
 | 
					
						
							|  |  |  |  * | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  |  * Copyright (C) 2003-5, 2007 Red Hat, Inc. All Rights Reserved. | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  |  * Written by David Howells (dhowells@redhat.com) | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * This program is free software; you can redistribute it and/or | 
					
						
							|  |  |  |  * modify it under the terms of the GNU General Public License | 
					
						
							|  |  |  |  * as published by the Free Software Foundation; either version | 
					
						
							|  |  |  |  * 2 of the License, or (at your option) any later version. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #ifndef _INTERNAL_H
 | 
					
						
							|  |  |  | #define _INTERNAL_H
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | #include <linux/key-type.h>
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | #include <linux/key-ui.h>
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | static inline __attribute__((format(printf, 1, 2))) | 
					
						
							|  |  |  | void no_printk(const char *fmt, ...) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #ifdef __KDEBUG
 | 
					
						
							|  |  |  | #define kenter(FMT, ...) \
 | 
					
						
							| 
									
										
										
										
											2008-03-06 10:03:59 +11:00
										 |  |  | 	printk(KERN_DEBUG "==> %s("FMT")\n", __func__, ##__VA_ARGS__) | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | #define kleave(FMT, ...) \
 | 
					
						
							| 
									
										
										
										
											2008-03-06 10:03:59 +11:00
										 |  |  | 	printk(KERN_DEBUG "<== %s()"FMT"\n", __func__, ##__VA_ARGS__) | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | #define kdebug(FMT, ...) \
 | 
					
						
							|  |  |  | 	printk(KERN_DEBUG "xxx" FMT"yyy\n", ##__VA_ARGS__) | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | #else
 | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | #define kenter(FMT, ...) \
 | 
					
						
							| 
									
										
										
										
											2008-03-06 10:03:59 +11:00
										 |  |  | 	no_printk(KERN_DEBUG "==> %s("FMT")\n", __func__, ##__VA_ARGS__) | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | #define kleave(FMT, ...) \
 | 
					
						
							| 
									
										
										
										
											2008-03-06 10:03:59 +11:00
										 |  |  | 	no_printk(KERN_DEBUG "<== %s()"FMT"\n", __func__, ##__VA_ARGS__) | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | #define kdebug(FMT, ...) \
 | 
					
						
							|  |  |  | 	no_printk(KERN_DEBUG FMT"\n", ##__VA_ARGS__) | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | extern struct key_type key_type_user; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*****************************************************************************/ | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * keep track of keys for a user | 
					
						
							|  |  |  |  * - this needs to be separate to user_struct to avoid a refcount-loop | 
					
						
							|  |  |  |  *   (user_struct pins some keyrings which pin this struct) | 
					
						
							|  |  |  |  * - this also keeps track of keys under request from userspace for this UID | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | struct key_user { | 
					
						
							|  |  |  | 	struct rb_node		node; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | 	struct mutex		cons_lock;	/* construction initiation lock */ | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 	spinlock_t		lock; | 
					
						
							|  |  |  | 	atomic_t		usage;		/* for accessing qnkeys & qnbytes */ | 
					
						
							|  |  |  | 	atomic_t		nkeys;		/* number of keys */ | 
					
						
							|  |  |  | 	atomic_t		nikeys;		/* number of instantiated keys */ | 
					
						
							|  |  |  | 	uid_t			uid; | 
					
						
							|  |  |  | 	int			qnkeys;		/* number of keys allocated to this user */ | 
					
						
							|  |  |  | 	int			qnbytes;	/* number of bytes allocated to this user */ | 
					
						
							|  |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern struct rb_root	key_user_tree; | 
					
						
							|  |  |  | extern spinlock_t	key_user_lock; | 
					
						
							|  |  |  | extern struct key_user	root_key_user; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern struct key_user *key_user_lookup(uid_t uid); | 
					
						
							|  |  |  | extern void key_user_put(struct key_user *user); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:32 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * key quota limits | 
					
						
							|  |  |  |  * - root has its own separate limits to everyone else | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | extern unsigned key_quota_root_maxkeys; | 
					
						
							|  |  |  | extern unsigned key_quota_root_maxbytes; | 
					
						
							|  |  |  | extern unsigned key_quota_maxkeys; | 
					
						
							|  |  |  | extern unsigned key_quota_maxbytes; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #define KEYQUOTA_LINK_BYTES	4		/* a link in a keyring is worth 4 bytes */
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern struct rb_root key_serial_tree; | 
					
						
							|  |  |  | extern spinlock_t key_serial_lock; | 
					
						
							| 
									
										
										
										
											2007-10-16 23:29:46 -07:00
										 |  |  | extern struct mutex key_construction_mutex; | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | extern wait_queue_head_t request_key_conswq; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern int __key_link(struct key *keyring, struct key *key); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-09-28 17:03:15 +01:00
										 |  |  | extern key_ref_t __keyring_search_one(key_ref_t keyring_ref, | 
					
						
							|  |  |  | 				      const struct key_type *type, | 
					
						
							|  |  |  | 				      const char *description, | 
					
						
							|  |  |  | 				      key_perm_t perm); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | extern struct key *keyring_search_instkey(struct key *keyring, | 
					
						
							|  |  |  | 					  key_serial_t target_id); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | typedef int (*key_match_func_t)(const struct key *, const void *); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-09-28 17:03:15 +01:00
										 |  |  | extern key_ref_t keyring_search_aux(key_ref_t keyring_ref, | 
					
						
							|  |  |  | 				    struct task_struct *tsk, | 
					
						
							|  |  |  | 				    struct key_type *type, | 
					
						
							|  |  |  | 				    const void *description, | 
					
						
							|  |  |  | 				    key_match_func_t match); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-09-28 17:03:15 +01:00
										 |  |  | extern key_ref_t search_process_keyrings(struct key_type *type, | 
					
						
							|  |  |  | 					 const void *description, | 
					
						
							|  |  |  | 					 key_match_func_t match, | 
					
						
							|  |  |  | 					 struct task_struct *tsk); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:31 -07:00
										 |  |  | extern struct key *find_keyring_by_name(const char *name, bool skip_perm_check); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | extern int install_thread_keyring(struct task_struct *tsk); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | extern int install_process_keyring(struct task_struct *tsk); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern struct key *request_key_and_link(struct key_type *type, | 
					
						
							|  |  |  | 					const char *description, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 					const void *callout_info, | 
					
						
							|  |  |  | 					size_t callout_len, | 
					
						
							| 
									
										
										
										
											2006-06-29 02:24:28 -07:00
										 |  |  | 					void *aux, | 
					
						
							| 
									
										
										
										
											2006-06-26 00:24:50 -07:00
										 |  |  | 					struct key *dest_keyring, | 
					
						
							|  |  |  | 					unsigned long flags); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * request_key authorisation | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | struct request_key_auth { | 
					
						
							|  |  |  | 	struct key		*target_key; | 
					
						
							|  |  |  | 	struct task_struct	*context; | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 	void			*callout_info; | 
					
						
							|  |  |  | 	size_t			callout_len; | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 	pid_t			pid; | 
					
						
							|  |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern struct key_type key_type_request_key_auth; | 
					
						
							|  |  |  | extern struct key *request_key_auth_new(struct key *target, | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:24 -07:00
										 |  |  | 					const void *callout_info, | 
					
						
							|  |  |  | 					size_t callout_len); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | extern struct key *key_get_instantiation_authkey(key_serial_t target_id); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * keyctl functions | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | extern long keyctl_get_keyring_ID(key_serial_t, int); | 
					
						
							|  |  |  | extern long keyctl_join_session_keyring(const char __user *); | 
					
						
							|  |  |  | extern long keyctl_update_key(key_serial_t, const void __user *, size_t); | 
					
						
							|  |  |  | extern long keyctl_revoke_key(key_serial_t); | 
					
						
							|  |  |  | extern long keyctl_keyring_clear(key_serial_t); | 
					
						
							|  |  |  | extern long keyctl_keyring_link(key_serial_t, key_serial_t); | 
					
						
							|  |  |  | extern long keyctl_keyring_unlink(key_serial_t, key_serial_t); | 
					
						
							|  |  |  | extern long keyctl_describe_key(key_serial_t, char __user *, size_t); | 
					
						
							|  |  |  | extern long keyctl_keyring_search(key_serial_t, const char __user *, | 
					
						
							|  |  |  | 				  const char __user *, key_serial_t); | 
					
						
							|  |  |  | extern long keyctl_read_key(key_serial_t, char __user *, size_t); | 
					
						
							|  |  |  | extern long keyctl_chown_key(key_serial_t, uid_t, gid_t); | 
					
						
							|  |  |  | extern long keyctl_setperm_key(key_serial_t, key_perm_t); | 
					
						
							|  |  |  | extern long keyctl_instantiate_key(key_serial_t, const void __user *, | 
					
						
							|  |  |  | 				   size_t, key_serial_t); | 
					
						
							|  |  |  | extern long keyctl_negate_key(key_serial_t, unsigned, key_serial_t); | 
					
						
							| 
									
										
											  
											
												[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
 (1) There's a new special key type called ".request_key_auth".
     This is an authorisation key for when one process requests a key and
     another process is started to construct it. This type of key cannot be
     created by the user; nor can it be requested by kernel services.
     Authorisation keys hold two references:
     (a) Each refers to a key being constructed. When the key being
     	 constructed is instantiated the authorisation key is revoked,
     	 rendering it of no further use.
     (b) The "authorising process". This is either:
     	 (i) the process that called request_key(), or:
     	 (ii) if the process that called request_key() itself had an
     	      authorisation key in its session keyring, then the authorising
     	      process referred to by that authorisation key will also be
     	      referred to by the new authorisation key.
	 This means that the process that initiated a chain of key requests
	 will authorise the lot of them, and will, by default, wind up with
	 the keys obtained from them in its keyrings.
 (2) request_key() creates an authorisation key which is then passed to
     /sbin/request-key in as part of a new session keyring.
 (3) When request_key() is searching for a key to hand back to the caller, if
     it comes across an authorisation key in the session keyring of the
     calling process, it will also search the keyrings of the process
     specified therein and it will use the specified process's credentials
     (fsuid, fsgid, groups) to do that rather than the calling process's
     credentials.
     This allows a process started by /sbin/request-key to find keys belonging
     to the authorising process.
 (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
     direct read or search permission if that key is contained within the
     keyrings of a process specified by an authorisation key found within the
     calling process's session keyring, and is searchable using the
     credentials of the authorising process.
     This allows a process started by /sbin/request-key to read keys belonging
     to the authorising process.
 (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
     KEYCTL_NEGATE will specify a keyring of the authorising process, rather
     than the process doing the instantiation.
 (6) One of the process keyrings can be nominated as the default to which
     request_key() should attach new keys if not otherwise specified. This is
     done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
     constants. The current setting can also be read using this call.
 (7) request_key() is partially interruptible. If it is waiting for another
     process to finish constructing a key, it can be interrupted. This permits
     a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
											
										 
											2005-06-23 22:00:56 -07:00
										 |  |  | extern long keyctl_set_reqkey_keyring(int); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:43 -08:00
										 |  |  | extern long keyctl_set_timeout(key_serial_t, unsigned); | 
					
						
							| 
									
										
										
										
											2006-01-08 01:02:47 -08:00
										 |  |  | extern long keyctl_assume_authority(key_serial_t); | 
					
						
							| 
									
										
										
										
											2008-04-29 01:01:26 -07:00
										 |  |  | extern long keyctl_get_security(key_serial_t keyid, char __user *buffer, | 
					
						
							|  |  |  | 				size_t buflen); | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * debugging key validation | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | #ifdef KEY_DEBUGGING
 | 
					
						
							|  |  |  | extern void __key_check(const struct key *); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static inline void key_check(const struct key *key) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	if (key && (IS_ERR(key) || key->magic != KEY_DEBUG_MAGIC)) | 
					
						
							|  |  |  | 		__key_check(key); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #else
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #define key_check(key) do {} while(0)
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #endif /* _INTERNAL_H */
 |