aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/keys-request-key.txt
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2006-01-08 04:02:47 -0500
committerLinus Torvalds <torvalds@g5.osdl.org>2006-01-08 23:13:53 -0500
commitb5f545c880a2a47947ba2118b2509644ab7a2969 (patch)
tree8720e02262b0ff6309ae79603f6c63965296d378 /Documentation/keys-request-key.txt
parentcab8eb594e84b434d20412fc5a3985b0bee3ab9f (diff)
[PATCH] keys: Permit running process to instantiate keys
Make it possible for a running process (such as gssapid) to be able to instantiate a key, as was requested by Trond Myklebust for NFS4. The patch makes the following changes: (1) A new, optional key type method has been added. This permits a key type to intercept requests at the point /sbin/request-key is about to be spawned and do something else with them - passing them over the rpc_pipefs files or netlink sockets for instance. The uninstantiated key, the authorisation key and the intended operation name are passed to the method. (2) The callout_info is no longer passed as an argument to /sbin/request-key to prevent unauthorised viewing of this data using ps or by looking in /proc/pid/cmdline. This means that the old /sbin/request-key program will not work with the patched kernel as it will expect to see an extra argument that is no longer there. A revised keyutils package will be made available tomorrow. (3) The callout_info is now attached to the authorisation key. Reading this key will retrieve the information. (4) A new field has been added to the task_struct. This holds the authorisation key currently active for a thread. Searches now look here for the caller's set of keys rather than looking for an auth key in the lowest level of the session keyring. This permits a thread to be servicing multiple requests at once and to switch between them. Note that this is per-thread, not per-process, and so is usable in multithreaded programs. The setting of this field is inherited across fork and exec. (5) A new keyctl function (KEYCTL_ASSUME_AUTHORITY) has been added that permits a thread to assume the authority to deal with an uninstantiated key. Assumption is only permitted if the authorisation key associated with the uninstantiated key is somewhere in the thread's keyrings. This function can also clear the assumption. (6) A new magic key specifier has been added to refer to the currently assumed authorisation key (KEY_SPEC_REQKEY_AUTH_KEY). (7) Instantiation will only proceed if the appropriate authorisation key is assumed first. The assumed authorisation key is discarded if instantiation is successful. (8) key_validate() is moved from the file of request_key functions to the file of permissions functions. (9) The documentation is updated. From: <Valdis.Kletnieks@vt.edu> Build fix. Signed-off-by: David Howells <dhowells@redhat.com> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Cc: Alexander Zangerl <az@bond.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Documentation/keys-request-key.txt')
-rw-r--r--Documentation/keys-request-key.txt22
1 files changed, 12 insertions, 10 deletions
diff --git a/Documentation/keys-request-key.txt b/Documentation/keys-request-key.txt
index 5f2b9c5edbb5..22488d791168 100644
--- a/Documentation/keys-request-key.txt
+++ b/Documentation/keys-request-key.txt
@@ -56,10 +56,12 @@ A request proceeds in the following manner:
56 (4) request_key() then forks and executes /sbin/request-key with a new session 56 (4) request_key() then forks and executes /sbin/request-key with a new session
57 keyring that contains a link to auth key V. 57 keyring that contains a link to auth key V.
58 58
59 (5) /sbin/request-key execs an appropriate program to perform the actual 59 (5) /sbin/request-key assumes the authority associated with key U.
60
61 (6) /sbin/request-key execs an appropriate program to perform the actual
60 instantiation. 62 instantiation.
61 63
62 (6) The program may want to access another key from A's context (say a 64 (7) The program may want to access another key from A's context (say a
63 Kerberos TGT key). It just requests the appropriate key, and the keyring 65 Kerberos TGT key). It just requests the appropriate key, and the keyring
64 search notes that the session keyring has auth key V in its bottom level. 66 search notes that the session keyring has auth key V in its bottom level.
65 67
@@ -67,19 +69,19 @@ A request proceeds in the following manner:
67 UID, GID, groups and security info of process A as if it was process A, 69 UID, GID, groups and security info of process A as if it was process A,
68 and come up with key W. 70 and come up with key W.
69 71
70 (7) The program then does what it must to get the data with which to 72 (8) The program then does what it must to get the data with which to
71 instantiate key U, using key W as a reference (perhaps it contacts a 73 instantiate key U, using key W as a reference (perhaps it contacts a
72 Kerberos server using the TGT) and then instantiates key U. 74 Kerberos server using the TGT) and then instantiates key U.
73 75
74 (8) Upon instantiating key U, auth key V is automatically revoked so that it 76 (9) Upon instantiating key U, auth key V is automatically revoked so that it
75 may not be used again. 77 may not be used again.
76 78
77 (9) The program then exits 0 and request_key() deletes key V and returns key 79(10) The program then exits 0 and request_key() deletes key V and returns key
78 U to the caller. 80 U to the caller.
79 81
80This also extends further. If key W (step 5 above) didn't exist, key W would be 82This also extends further. If key W (step 7 above) didn't exist, key W would be
81created uninstantiated, another auth key (X) would be created [as per step 3] 83created uninstantiated, another auth key (X) would be created (as per step 3)
82and another copy of /sbin/request-key spawned [as per step 4]; but the context 84and another copy of /sbin/request-key spawned (as per step 4); but the context
83specified by auth key X will still be process A, as it was in auth key V. 85specified by auth key X will still be process A, as it was in auth key V.
84 86
85This is because process A's keyrings can't simply be attached to 87This is because process A's keyrings can't simply be attached to
@@ -138,8 +140,8 @@ until one succeeds:
138 140
139 (3) The process's session keyring is searched. 141 (3) The process's session keyring is searched.
140 142
141 (4) If the process has a request_key() authorisation key in its session 143 (4) If the process has assumed the authority associated with a request_key()
142 keyring then: 144 authorisation key then:
143 145
144 (a) If extant, the calling process's thread keyring is searched. 146 (a) If extant, the calling process's thread keyring is searched.
145 147