KEYS: Split role of the keyring pointer for keyring restrict functions

The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.

Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.

Signed-off-by: Mat Martineau <[email protected]>
This commit is contained in:
Mat Martineau 2016-08-30 11:33:13 -07:00
commit aaf66c8838
8 changed files with 39 additions and 25 deletions

View file

@ -1054,10 +1054,10 @@ payload contents" for more information.
can be verified by a key the kernel already has.
When called, the restriction function will be passed the keyring being
added to, the key flags value and the type and payload of the key being
added. Note that when a new key is being created, this is called between
payload preparsing and actual key creation. The function should return 0
to allow the link or an error to reject it.
added to, the key type, the payload of the key being added, and data to be
used in the restriction check. Note that when a new key is being created,
this is called between payload preparsing and actual key creation. The
function should return 0 to allow the link or an error to reject it.
A convenience function, restrict_link_reject, exists to always return
-EPERM to in this case.