Changes in Makefile

601f0093 - KEYS: remove CONFIG_KEYS_COMPAT

Wed, 09 Oct 2019 23:04:43 +0000

KEYS: remove CONFIG_KEYS_COMPATKEYS_COMPAT now always takes the value of COMPAT && KEYS. But thesecurity/keys/ directory is only compiled if KEYS is enabled, so inpractice KEYS_COMPAT is the same as COMPAT. Therefore, remove theunnecessary KEYS_COMPAT and just use COMPAT directly.(Also remove an outdated comment from compat.c.)Reviewed-by: James Morris Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/security/keys/Makefile

47f9c279 - KEYS: trusted: Create trusted keys subsystem

Wed, 16 Oct 2019 05:14:54 +0000

KEYS: trusted: Create trusted keys subsystemMove existing code to trusted keys subsystem. Also, rename files with"tpm" as suffix which provides the underlying implementation.Suggested-by: Jarkko Sakkinen Signed-off-by: Sumit Garg Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/security/keys/Makefile

00d60fd3 - KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]

Tue, 09 Oct 2018 16:46:59 +0000

KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]Provide five keyctl functions that permit userspace to make use of the newkey type ops for accessing and driving asymmetric keys. (*) Query an asymmetric key. long keyctl(KEYCTL_PKEY_QUERY, key_serial_t key, unsigned long reserved, struct keyctl_pkey_query *info); Get information about an asymmetric key. The information is returned in the keyctl_pkey_query struct: __u32 supported_ops; A bit mask of flags indicating which ops are supported. This is constructed from a bitwise-OR of: KEYCTL_SUPPORTS_{ENCRYPT,DECRYPT,SIGN,VERIFY} __u32 key_size; The size in bits of the key. __u16 max_data_size; __u16 max_sig_size; __u16 max_enc_size; __u16 max_dec_size; The maximum sizes in bytes of a blob of data to be signed, a signature blob, a blob to be encrypted and a blob to be decrypted. reserved must be set to 0. This is intended for future use to hand over one or more passphrases needed unlock a key. If successful, 0 is returned. If the key is not an asymmetric key, EOPNOTSUPP is returned. (*) Encrypt, decrypt, sign or verify a blob using an asymmetric key. long keyctl(KEYCTL_PKEY_ENCRYPT, const struct keyctl_pkey_params *params, const char *info, const void *in, void *out); long keyctl(KEYCTL_PKEY_DECRYPT, const struct keyctl_pkey_params *params, const char *info, const void *in, void *out); long keyctl(KEYCTL_PKEY_SIGN, const struct keyctl_pkey_params *params, const char *info, const void *in, void *out); long keyctl(KEYCTL_PKEY_VERIFY, const struct keyctl_pkey_params *params, const char *info, const void *in, const void *in2); Use an asymmetric key to perform a public-key cryptographic operation a blob of data. The parameter block pointed to by params contains a number of integer values: __s32 key_id; __u32 in_len; __u32 out_len; __u32 in2_len; For a given operation, the in and out buffers are used as follows: Operation ID in,in_len out,out_len in2,in2_len ======================= =============== =============== =========== KEYCTL_PKEY_ENCRYPT Raw data Encrypted data - KEYCTL_PKEY_DECRYPT Encrypted data Raw data - KEYCTL_PKEY_SIGN Raw data Signature - KEYCTL_PKEY_VERIFY Raw data - Signature info is a string of key=value pairs that supply supplementary information. The __spare space in the parameter block must be set to 0. This is intended, amongst other things, to allow the passing of passphrases required to unlock a key. If successful, encrypt, decrypt and sign all return the amount of data written into the output buffer. Verification returns 0 on success.Signed-off-by: David Howells Tested-by: Marcel Holtmann Reviewed-by: Marcel Holtmann Reviewed-by: Denis Kenzior Tested-by: Denis Kenzior Signed-off-by: James Morris List of files: /linux-6.15/security/keys/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/security/keys/Makefile

f1c316a3 - KEYS: add SP800-56A KDF support for DH

Fri, 19 Aug 2016 18:39:09 +0000

KEYS: add SP800-56A KDF support for DHSP800-56A defines the use of DH with key derivation function based on acounter. The input to the KDF is defined as (DH shared secret || otherinformation). The value for the "other information" is to be provided bythe caller.The KDF is implemented using the hash support from the kernel crypto API.The implementation uses the symmetric hash support as the input to thehash operation is usually very small. The caller is allowed to specifythe hash name that he wants to use to derive the key material allowingthe use of all supported hashes provided with the kernel crypto API.As the KDF implements the proper truncation of the DH shared secret tothe requested size, this patch fills the caller buffer up to its size.The patch is tested with a new test added to the keyutils user spacecode which uses a CAVS test vector testing the compliance withSP800-56A.Signed-off-by: Stephan Mueller Signed-off-by: David Howells List of files: /linux-6.15/security/keys/Makefile

ddbb4114 - KEYS: Add KEYCTL_DH_COMPUTE command

Tue, 12 Apr 2016 18:54:58 +0000

KEYS: Add KEYCTL_DH_COMPUTE commandThis adds userspace access to Diffie-Hellman computations through anew keyctl() syscall command to calculate shared secrets or publickeys using input parameters stored in the keyring.Input key ids are provided in a struct due to the current 5-arg limitfor the keyctl syscall. Only user keys are supported in order to avoidexposing the content of logon or encrypted keys.The output is written to the provided buffer, based on the assumptionthat the values are only needed in userspace.Future support for other types of key derivation would involve a newcommand, like KEYCTL_ECDH_COMPUTE.Once Diffie-Hellman support is included in the crypto API, this codecan be converted to use the crypto API to take advantage of possiblehardware acceleration and reduce redundant code.Signed-off-by: Mat Martineau Signed-off-by: David Howells List of files: /linux-6.15/security/keys/Makefile

f36f8c75 - KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches

Tue, 24 Sep 2013 09:35:19 +0000

KEYS: Add per-user_namespace registers for persistent per-UID kerberos cachesAdd support for per-user_namespace registers of persistent per-UID kerberoscaches held within the kernel.This allows the kerberos cache to be retained beyond the life of all a user'sprocesses so that the user's cron jobs can work.The kerberos cache is envisioned as a keyring/key tree looking something like: struct user_namespace \___ .krb_cache keyring - The register \___ _krb.0 keyring - Root's Kerberos cache \___ _krb.5000 keyring - User 5000's Kerberos cache \___ _krb.5001 keyring - User 5001's Kerberos cache \___ tkt785 big_key - A ccache blob \___ tkt12345 big_key - Another ccache blobOr possibly: struct user_namespace \___ .krb_cache keyring - The register \___ _krb.0 keyring - Root's Kerberos cache \___ _krb.5000 keyring - User 5000's Kerberos cache \___ _krb.5001 keyring - User 5001's Kerberos cache \___ tkt785 keyring - A ccache \___ krbtgt/REDHAT.COM@REDHAT.COM big_key \___ http/REDHAT.COM@REDHAT.COM user \___ afs/REDHAT.COM@REDHAT.COM user \___ nfs/REDHAT.COM@REDHAT.COM user \___ krbtgt/KERNEL.ORG@KERNEL.ORG big_key \___ http/KERNEL.ORG@KERNEL.ORG big_keyWhat goes into a particular Kerberos cache is entirely up to userspace. Kernelsupport is limited to giving you the Kerberos cache keyring that you want.The user asks for their Kerberos cache by: krb_cache = keyctl_get_krbcache(uid, dest_keyring);The uid is -1 or the user's own UID for the user's own cache or the uid of someother user's cache (requires CAP_SETUID). This permits rpc.gssd or whatever tomess with the cache.The cache returned is a keyring named "_krb." that the possessor can read,search, clear, invalidate, unlink from and add links to. Active LSMs get achance to rule on whether the caller is permitted to make a link.Each uid's cache keyring is created when it first accessed and is given atimeout that is extended each time this function is called so that the keyringgoes away after a while. The timeout is configurable by sysctl but defaults tothree days.Each user_namespace struct gets a lazily-created keyring that serves as theregister. The cache keyrings are added to it. This means that standard keysearch and garbage collection facilities are available.The user_namespace struct's register goes away when it does and anything leftin it is then automatically gc'd.Signed-off-by: David Howells Tested-by: Simo Sorce cc: Serge E. Hallyn cc: Eric W. Biederman List of files: /linux-6.15/security/keys/Makefile

ab3c3587 - KEYS: Implement a big key type that can save to tmpfs

Tue, 24 Sep 2013 09:35:18 +0000

KEYS: Implement a big key type that can save to tmpfsImplement a big key type that can save its contents to tmpfs and thusswapspace when memory is tight. This is useful for Kerberos ticket caches.Signed-off-by: David Howells Tested-by: Simo Sorce List of files: /linux-6.15/security/keys/Makefile

9f7ce8e2 - KEYS: Reorganise keys Makefile

Fri, 11 May 2012 09:56:56 +0000

KEYS: Reorganise keys MakefileReorganise the keys directory Makefile to put all the core bits together andthe type-specific bits after.Signed-off-by: David Howells Acked-by: Mimi Zohar List of files: /linux-6.15/security/keys/Makefile

61cf45d0 - encrypted-keys: create encrypted-keys directory

Wed, 14 Sep 2011 19:06:00 +0000

encrypted-keys: create encrypted-keys directoryMove all files associated with encrypted keys to keys/encrypted-keys.Signed-off-by: Mimi Zohar List of files: /linux-6.15/security/keys/Makefile

79a73d18 - encrypted-keys: add ecryptfs format support

Mon, 27 Jun 2011 11:45:44 +0000

encrypted-keys: add ecryptfs format supportThe 'encrypted' key type defines its own payload format which contains asymmetric key randomly generated that cannot be used directly to mountan eCryptfs filesystem, because it expects an authentication tokenstructure.This patch introduces the new format 'ecryptfs' that allows to store anauthentication token structure inside the encrypted key payload containinga randomly generated symmetric key, as the same for the format 'default'.More details about the usage of encrypted keys with the eCryptfsfilesystem can be found in the file 'Documentation/keys-ecryptfs.txt'.Signed-off-by: Roberto Sassu Acked-by: Gianluca Ramunno Acked-by: Tyler Hicks Signed-off-by: Mimi Zohar List of files: /linux-6.15/security/keys/Makefile

b9703449 - encrypted-keys: rename encrypted_defined files to encrypted

Tue, 18 Jan 2011 14:07:12 +0000

encrypted-keys: rename encrypted_defined files to encryptedRename encrypted_defined.c and encrypted_defined.h files to encrypted.c andencrypted.h, respectively. Based on request from David Howells.Signed-off-by: Mimi Zohar Acked-by: David Howells Signed-off-by: James Morris List of files: /linux-6.15/security/keys/Makefile

4b174b6d - trusted-keys: rename trusted_defined files to trusted

Tue, 18 Jan 2011 14:07:11 +0000

trusted-keys: rename trusted_defined files to trustedRename trusted_defined.c and trusted_defined.h files to trusted.c andtrusted.h, respectively. Based on request from David Howells.Signed-off-by: Mimi Zohar Acked-by: David Howells Signed-off-by: James Morris List of files: /linux-6.15/security/keys/Makefile

7e70cb49 - keys: add new key-type encrypted

Tue, 23 Nov 2010 23:55:35 +0000

keys: add new key-type encryptedDefine a new kernel key-type called 'encrypted'. Encrypted keys are kernelgenerated random numbers, which are encrypted/decrypted with a 'trusted'symmetric key. Encrypted keys are created/encrypted/decrypted in the kernel.Userspace only ever sees/stores encrypted blobs.Changelog:- bug fix: replaced master-key rcu based locking with semaphore (reported by David Howells)- Removed memset of crypto_shash_digest() digest output- Replaced verification of 'key-type:key-desc' using strcspn(), with one based on string constants.- Moved documentation to Documentation/keys-trusted-encrypted.txt- Replace hash with shash (based on comments by David Howells)- Make lengths/counts size_t where possible (based on comments by David Howells) Could not convert most lengths, as crypto expects 'unsigned int' (size_t: on 32 bit is defined as unsigned int, but on 64 bit is unsigned long)- Add 'const' where possible (based on comments by David Howells)- allocate derived_buf dynamically to support arbitrary length master key (fixed by Roberto Sassu)- wait until late_initcall for crypto libraries to be registered- cleanup security/Kconfig- Add missing 'update' keyword (reported/fixed by Roberto Sassu)- Free epayload on failure to create key (reported/fixed by Roberto Sassu)- Increase the data size limit (requested by Roberto Sassu)- Crypto return codes are always 0 on success and negative on failure, remove unnecessary tests.- Replaced kzalloc() with kmalloc()Signed-off-by: Mimi Zohar Signed-off-by: David Safford Reviewed-by: Roberto Sassu Signed-off-by: James Morris List of files: /linux-6.15/security/keys/Makefile

d00a1c72 - keys: add new trusted key-type

Tue, 23 Nov 2010 22:50:34 +0000

keys: add new trusted key-typeDefine a new kernel key-type called 'trusted'. Trusted keys are randomnumber symmetric keys, generated and RSA-sealed by the TPM. The TPMonly unseals the keys, if the boot PCRs and other criteria match.Userspace can only ever see encrypted blobs.Based on suggestions by Jason Gunthorpe, several new options have beenadded to support additional usages.The new options are:migratable= designates that the key may/may not ever be updated (resealed under a new key, new pcrinfo or new auth.)pcrlock=n extends the designated PCR 'n' with a random value, so that a key sealed to that PCR may not be unsealed again until after a reboot.keyhandle= specifies the sealing/unsealing key handle.keyauth= specifies the sealing/unsealing key auth.blobauth= specifies the sealed data auth.Implementation of a kernel reserved locality for trusted keys will beinvestigated for a possible future extension.Changelog:- Updated and added examples to Documentation/keys-trusted-encrypted.txt- Moved generic TPM constants to include/linux/tpm_command.h (David Howell's suggestion.)- trusted_defined.c: replaced kzalloc with kmalloc, added pcrlock failure error handling, added const qualifiers where appropriate.- moved to late_initcall- updated from hash to shash (suggestion by David Howells)- reduced worst stack usage (tpm_seal) from 530 to 312 bytes- moved documentation to Documentation directory (suggestion by David Howells)- all the other code cleanups suggested by David Howells- Add pcrlock CAP_SYS_ADMIN dependency (based on comment by Jason Gunthorpe)- New options: migratable, pcrlock, keyhandle, keyauth, blobauth (based on discussions with Jason Gunthorpe)- Free payload on failure to create key(reported/fixed by Roberto Sassu)- Updated Kconfig and other descriptions (based on Serge Hallyn's suggestion)- Replaced kzalloc() with kmalloc() (reported by Serge Hallyn)Signed-off-by: David Safford Signed-off-by: Mimi Zohar Signed-off-by: James Morris List of files: /linux-6.15/security/keys/Makefile

5d135440 - KEYS: Add garbage collection for dead, revoked and expired keys. [try #6]

Wed, 02 Sep 2009 08:14:00 +0000

KEYS: Add garbage collection for dead, revoked and expired keys. [try #6]Add garbage collection for dead, revoked and expired keys. This involvederasing all links to such keys from keyrings that point to them. At thatpoint, the key will be deleted in the normal manner.Keyrings from which garbage collection occurs are shrunk and their quotaconsumption reduced as appropriate.Dead keys (for which the key type has been removed) will be garbage collectedimmediately.Revoked and expired keys will hang around for a number of seconds, as set in/proc/sys/kernel/keys/gc_delay before being automatically removed. The defaultis 5 minutes.Signed-off-by: David Howells Signed-off-by: James Morris List of files: /linux-6.15/security/keys/Makefile

0b77f5bf - keys: make the keyring quotas controllable through /proc/sys

Tue, 29 Apr 2008 08:01:32 +0000

keys: make the keyring quotas controllable through /proc/sysMake the keyring quotas controllable through /proc/sys files: (*) /proc/sys/kernel/keys/root_maxkeys /proc/sys/kernel/keys/root_maxbytes Maximum number of keys that root may have and the maximum total number of bytes of data that root may have stored in those keys. (*) /proc/sys/kernel/keys/maxkeys /proc/sys/kernel/keys/maxbytes Maximum number of keys that each non-root user may have and the maximum total number of bytes of data that each of those users may have stored in their keys.Also increase the quotas as a number of people have been complaining that it'snot big enough. I'm not sure that it's big enough now either, but on theother hand, it can now be set in /etc/sysctl.conf.Signed-off-by: David Howells Cc: Cc: Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/security/keys/Makefile

468ed2b0 - [PATCH] Keys: Split key permissions checking into a .c file

Fri, 07 Oct 2005 14:07:38 +0000

[PATCH] Keys: Split key permissions checking into a .c fileThe attached patch splits key permissions checking out of key-ui.h andmoves it into a .c file. It's quite large and called quite a lot, andit's about to get bigger with the addition of LSM support for keys...key_any_permission() is also discarded as it's no longer used.Signed-Off-By: David Howells Signed-off-by: Linus Torvalds List of files: /linux-6.15/security/keys/Makefile

3e30148c - [PATCH] Keys: Make request-key create an authorisation key

Fri, 24 Jun 2005 05:00:56 +0000

[PATCH] Keys: Make request-key create an authorisation keyThe attached patch makes the following changes: (1) There's a new special key type called ".request_key_auth". This is an authorisation key for when one process requests a key and another process is started to construct it. This type of key cannot be created by the user; nor can it be requested by kernel services. Authorisation keys hold two references: (a) Each refers to a key being constructed. When the key being constructed is instantiated the authorisation key is revoked, rendering it of no further use. (b) The "authorising process". This is either: (i) the process that called request_key(), or: (ii) if the process that called request_key() itself had an authorisation key in its session keyring, then the authorising process referred to by that authorisation key will also be referred to by the new authorisation key. This means that the process that initiated a chain of key requests will authorise the lot of them, and will, by default, wind up with the keys obtained from them in its keyrings. (2) request_key() creates an authorisation key which is then passed to /sbin/request-key in as part of a new session keyring. (3) When request_key() is searching for a key to hand back to the caller, if it comes across an authorisation key in the session keyring of the calling process, it will also search the keyrings of the process specified therein and it will use the specified process's credentials (fsuid, fsgid, groups) to do that rather than the calling process's credentials. This allows a process started by /sbin/request-key to find keys belonging to the authorising process. (4) A key can be read, even if the process executing KEYCTL_READ doesn't have direct read or search permission if that key is contained within the keyrings of a process specified by an authorisation key found within the calling process's session keyring, and is searchable using the credentials of the authorising process. This allows a process started by /sbin/request-key to read keys belonging to the authorising process. (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or KEYCTL_NEGATE will specify a keyring of the authorising process, rather than the process doing the instantiation. (6) One of the process keyrings can be nominated as the default to which request_key() should attach new keys if not otherwise specified. This is done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_* constants. The current setting can also be read using this call. (7) request_key() is partially interruptible. If it is waiting for another process to finish constructing a key, it can be interrupted. This permits a request-key cycle to be broken without recourse to rebooting.Signed-Off-By: David Howells Signed-Off-By: Benoit Boissinot Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/security/keys/Makefile

1da177e4 - Linux-2.6.12-rc2

Sat, 16 Apr 2005 22:20:36 +0000

Linux-2.6.12-rc2Initial git repository build. I'm not bothering with the full history,even though we have it. We can create a separate "historical" gitarchive of that later if we want to, and in the meantime it's about3.2GB when imported into git - space that would just make the earlygit days unnecessarily complicated, when we don't have a lot of goodinfrastructure for it.Let it rip! List of files: /linux-6.15/security/keys/Makefile