Lines Matching refs:key
5 The key request service is part of the key retention service (refer to
12 struct key *request_key(const struct key_type *type,
18 struct key *request_key_with_auxdata(const struct key_type *type,
26 struct key *request_key_async(const struct key_type *type,
33 struct key *request_key_async_with_auxdata(const struct key_type *type,
47 does not need to link the key to a keyring to prevent it from being immediately
48 destroyed. The kernel interface returns a pointer directly to the key, and
49 it's up to the caller to destroy the key.
53 default is NULL). This is only useful for those key types that define their
54 own upcall mechanism rather than using /sbin/request-key.
60 The userspace interface links the key to a keyring associated with the process
61 to prevent the key from going away, and returns the serial number of the key to
65 The following example assumes that the key types involved don't define their
67 forking and execution of /sbin/request-key.
80 a suitable key there. If there is, it returns the key. If there isn't,
84 (3) request_key() sees that A doesn't have the desired key yet, so it creates
87 (a) An uninstantiated key U of requested type and description.
89 (b) An authorisation key V that refers to key U and notes that process A
90 is the context in which key U should be instantiated and secured, and
91 from which associated key requests may be satisfied.
93 (4) request_key() then forks and executes /sbin/request-key with a new session
94 keyring that contains a link to auth key V.
96 (5) /sbin/request-key assumes the authority associated with key U.
98 (6) /sbin/request-key execs an appropriate program to perform the actual
101 (7) The program may want to access another key from A's context (say a
102 Kerberos TGT key). It just requests the appropriate key, and the keyring
103 search notes that the session keyring has auth key V in its bottom level.
107 and come up with key W.
110 instantiate key U, using key W as a reference (perhaps it contacts a
111 Kerberos server using the TGT) and then instantiates key U.
113 (9) Upon instantiating key U, auth key V is automatically revoked so that it
116 (10) The program then exits 0 and request_key() deletes key V and returns key
119 This also extends further. If key W (step 7 above) didn't exist, key W would
120 be created uninstantiated, another auth key (X) would be created (as per step
121 3) and another copy of /sbin/request-key spawned (as per step 4); but the
122 context specified by auth key X will still be process A, as it was in auth key
126 /sbin/request-key at the appropriate places because (a) execve will discard two
134 Rather than instantiating a key, it is possible for the possessor of an
135 authorisation key to negatively instantiate a key that's under construction.
137 the key whilst it exists to fail with error ENOKEY if negated or the specified
140 This is provided to prevent excessive repeated spawning of /sbin/request-key
141 processes for a key that will never be obtainable.
143 Should the /sbin/request-key process exit anything other than 0 or die on a
144 signal, the key under construction will be automatically negatively
154 (1) When the key management code searches for a key (keyring_search_aux) it
158 (2) It considers all the non-keyring keys within that keyring and, if any key
160 if the key is allowed to be found. If it is, that key is returned; if
169 The process stops immediately a valid key is found with permission granted to
170 use it. Any error from a previous match attempt is discarded and the key is
183 authorisation key then:
191 The moment one succeeds, all pending errors are discarded and the found key is