diff options
author | David Howells <dhowells@redhat.com> | 2019-06-26 22:02:33 +0200 |
---|---|---|
committer | David Howells <dhowells@redhat.com> | 2019-06-28 00:02:12 +0200 |
commit | a58946c158a040068e7c94dc1d58bbd273258068 (patch) | |
tree | e655258b700359cdfd9f762c099b7587dc0eed9b /Documentation/security | |
parent | keys: Network namespace domain tag (diff) | |
download | linux-a58946c158a040068e7c94dc1d58bbd273258068.tar.xz linux-a58946c158a040068e7c94dc1d58bbd273258068.zip |
keys: Pass the network namespace into request_key mechanism
Create a request_key_net() function and use it to pass the network
namespace domain tag into DNS revolver keys and rxrpc/AFS keys so that keys
for different domains can coexist in the same keyring.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: linux-nfs@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: linux-afs@lists.infradead.org
Diffstat (limited to 'Documentation/security')
-rw-r--r-- | Documentation/security/keys/core.rst | 28 | ||||
-rw-r--r-- | Documentation/security/keys/request-key.rst | 29 |
2 files changed, 43 insertions, 14 deletions
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst index ae930ae9d590..0e74f372e58c 100644 --- a/Documentation/security/keys/core.rst +++ b/Documentation/security/keys/core.rst @@ -1102,26 +1102,42 @@ payload contents" for more information. See also Documentation/security/keys/request-key.rst. + * To search for a key in a specific domain, call: + + struct key *request_key_tag(const struct key_type *type, + const char *description, + struct key_tag *domain_tag, + const char *callout_info); + + This is identical to request_key(), except that a domain tag may be + specifies that causes search algorithm to only match keys matching that + tag. The domain_tag may be NULL, specifying a global domain that is + separate from any nominated domain. + + * To search for a key, passing auxiliary data to the upcaller, call:: struct key *request_key_with_auxdata(const struct key_type *type, const char *description, + struct key_tag *domain_tag, const void *callout_info, size_t callout_len, void *aux); - This is identical to request_key(), except that the auxiliary data is - passed to the key_type->request_key() op if it exists, and the callout_info - is a blob of length callout_len, if given (the length may be 0). + This is identical to request_key_tag(), except that the auxiliary data is + passed to the key_type->request_key() op if it exists, and the + callout_info is a blob of length callout_len, if given (the length may be + 0). * To search for a key under RCU conditions, call:: struct key *request_key_rcu(const struct key_type *type, - const char *description); + const char *description, + struct key_tag *domain_tag); - which is similar to request_key() except that it does not check for keys - that are under construction and it will not call out to userspace to + which is similar to request_key_tag() except that it does not check for + keys that are under construction and it will not call out to userspace to construct a key if it can't find a match. diff --git a/Documentation/security/keys/request-key.rst b/Documentation/security/keys/request-key.rst index 5a210baa583a..35f2296b704a 100644 --- a/Documentation/security/keys/request-key.rst +++ b/Documentation/security/keys/request-key.rst @@ -15,8 +15,16 @@ The process starts by either the kernel requesting a service by calling or:: + struct key *request_key_tag(const struct key_type *type, + const char *description, + const struct key_tag *domain_tag, + const char *callout_info); + +or:: + struct key *request_key_with_auxdata(const struct key_type *type, const char *description, + const struct key_tag *domain_tag, const char *callout_info, size_t callout_len, void *aux); @@ -24,7 +32,8 @@ or:: or:: struct key *request_key_rcu(const struct key_type *type, - const char *description); + const char *description, + const struct key_tag *domain_tag); Or by userspace invoking the request_key system call:: @@ -38,14 +47,18 @@ does not need to link the key to a keyring to prevent it from being immediately destroyed. The kernel interface returns a pointer directly to the key, and it's up to the caller to destroy the key. -The request_key_with_auxdata() calls is like the in-kernel request_key() call, -except that they permit auxiliary data to be passed to the upcaller (the -default is NULL). This is only useful for those key types that define their -own upcall mechanism rather than using /sbin/request-key. +The request_key_tag() call is like the in-kernel request_key(), except that it +also takes a domain tag that allows keys to be separated by namespace and +killed off as a group. + +The request_key_with_auxdata() calls is like the request_key_tag() call, except +that they permit auxiliary data to be passed to the upcaller (the default is +NULL). This is only useful for those key types that define their own upcall +mechanism rather than using /sbin/request-key. -The request_key_rcu() call is like the in-kernel request_key() call, except -that it doesn't check for keys that are under construction and doesn't attempt -to construct missing keys. +The request_key_rcu() call is like the request_key_tag() call, except that it +doesn't check for keys that are under construction and doesn't attempt to +construct missing keys. The userspace interface links the key to a keyring associated with the process to prevent the key from going away, and returns the serial number of the key to |