Lines Matching full:keys
5 This service allows cryptographic keys, authentication tokens, cross-domain
10 other keys. Processes each have three standard keyring subscriptions that a
11 kernel service can search for relevant keys.
25 In this context, keys represent units of cryptographic data, authentication
47 kernel by a kernel service (such as a filesystem) before keys of that type
53 Should a type be removed from the system, all the keys of that type will
65 instantiation function. Keys can also be immortal.
68 actual "key". In the case of a keyring, this is a list of keys to which
86 Keys being requested from userspace will be in this state.
96 * Expired. Keys can have lifetimes set. If their lifetime is exceeded,
105 Keys in the last three states are subject to garbage collection. See the
112 The key service provides a number of features besides keys:
118 Keyrings are special keys that contain a list of other keys. Keyring
136 separated from the rest of the description by a ':'. "logon" keys can
171 * Each user has two quotas against which the keys they own are tracked. One
172 limits the total number of keys and keyrings, the other limits the total
186 manipulate keys and keyrings.
189 for keys.
201 Keys have an owner user ID, a group access ID, and a permissions mask. The mask
213 keys.
222 This permits keyrings to be searched and keys to be found. Searches can
243 controls can be applied to keys created within various contexts. This support
250 newly-created keys. If the contents of that file correspond to an SELinux
254 particular context to newly-created keys, using the "create" permission in the
277 * /proc/keys
279 This lists the keys that are currently viewable by the task reading the
284 The only keys included in the list are those that grant View permission to
286 security checks are still performed, and may further filter out keys that
327 <inst>/<keys> Total number of keys and number instantiated
328 <keys>/<max> Key count quota
333 quota limits on keys:
335 * /proc/sys/kernel/keys/root_maxkeys
336 /proc/sys/kernel/keys/root_maxbytes
338 These files hold the maximum number of keys that root may have and the
340 keys.
342 * /proc/sys/kernel/keys/maxkeys
343 /proc/sys/kernel/keys/maxbytes
345 These files hold the maximum number of keys that each non-root user may
347 users may have stored in their keys.
356 Userspace can manipulate keys directly through three new syscalls: add_key,
358 manipulating keys.
362 values available for referring to special keys and keyrings that relate to the
409 User defined keys can be created by specifying type "user". It is
440 See also Documentation/security/keys/request-key.rst.
556 This function clears the list of keys attached to a keyring. The calling
579 Any links within the keyring to keys that match the new key in terms of
625 checked for keys before recursion into its children occurs.
629 permission on will be recursed into, and only keys and keyrings for which
652 representing the IDs of all the keys to which it is subscribed. The user
717 This sets the default keyring to which implicitly requested keys will be
754 or expired keys.
766 Once authority is assumed, searches for keys will also search the
826 keys from all keyrings and deletes the key when its reference count
829 Keys that are marked invalidated become invisible to normal key operations
830 immediately, though they are still visible in /proc/keys until deleted
841 The params struct contains serial numbers for three keys::
893 An existing keyring can restrict linkage of additional keys by evaluating
897 to. It may be empty or may already have keys linked. Existing linked keys
907 later unregistered, no keys may be added to the keyring after the key type
915 See Documentation/crypto/asymmetric-keys.rst for specific restrictions
929 Currently supported keys include ``enc`` and ``hash``. The information
1094 be broken down into two areas: keys and key types.
1096 Dealing with keys is fairly straightforward. Firstly, the kernel service
1100 call, and the key released upon close. How to deal with conflicting keys due to
1108 Specific key types should have a header file under include/keys/ that should be
1109 used to access that type. For keys of type "user", for example, that would be::
1111 <keys/user-type.h>
1113 Note that there are two different types of pointers to keys that may be
1161 implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
1163 See also Documentation/security/keys/request-key.rst.
1174 specifies that causes search algorithm to only match keys matching that
1201 keys that are under construction and it will not call out to userspace to
1223 Keys so references will need to be disposed of by calling key_put() when
1280 An example of using this is to manage rings of cryptographic keys that are
1281 set up when the kernel boots where userspace is also permitted to add keys
1317 Under some circumstances, it may be desirable to deal with a bundle of keys.
1342 instantiated (uninstantiated keys cannot be "found").
1547 description to narrow down the search to a small number of keys.
1550 keys in the keyring until one is matched. This must be used for any
1567 If match_preparse() is not provided, keys of this type will be matched
1601 This method is optional. It is called during /proc/keys reading to
1808 access any more keys. It may then look around for a user specific process to
1842 Dead keys (for which the type has been removed) will be automatically unlinked
1846 Similarly, revoked and expired keys will be garbage collected, but only after a
1849 /proc/sys/kernel/keys/gc_delay