mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 19:21:31 -04:00
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:
parent
469ff8f7d4
commit
aaf66c8838
8 changed files with 39 additions and 25 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue