mirror of https://github.com/mkerrisk/man-pages
keyrings.7, persistent-keyring.7, process-keyring.7, session-keyring.7, thread-keyring.7, user-keyring.7, user-session-keyring.7: Rewrap source lines
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk
parent
1ba9d9e551
commit
a44454bc1b
183
man7/keyrings.7
183
man7/keyrings.7
|
|
@ -24,7 +24,8 @@ System call interfaces are provided so that userspace programs can manage those
|
|||
objects and also use the facility for their own purposes.
|
||||
.P
|
||||
A library and some userspace utilities are provided to allow access to the
|
||||
facility. See
|
||||
facility.
|
||||
See
|
||||
.BR keyutils (7)
|
||||
manual page for more information.
|
||||
.P
|
||||
|
|
@ -60,41 +61,50 @@ A 'key' contains the following elements:
|
|||
This is a unique integer handle by which a key is referred to in system call
|
||||
arguments.
|
||||
.IP "\fBType\fR"
|
||||
This defines what sort of data can be held in the key, how the proposed content
|
||||
of the key will be parsed and how the payload will be used.
|
||||
This defines what sort of data can be held in the key,
|
||||
how the proposed content of the key will be parsed and
|
||||
how the payload will be used.
|
||||
.IP
|
||||
There are a number of general purpose types available, plus some specialist
|
||||
types defined by specific drivers.
|
||||
.IP "\fBDescription\fR"
|
||||
This is a printable string that is used as the search term for the key (in
|
||||
conjunction with the type) as well as a display name. The description may be
|
||||
partially matched or exactly matched.
|
||||
conjunction with the type) as well as a display name.
|
||||
The description may be partially matched or exactly matched.
|
||||
.IP "\fBPayload\fR"
|
||||
This is the actual content of a key. This is usually set when a key is
|
||||
created, but it is possible for the kernel to upcall to userspace to finish the
|
||||
instantiation of a key if that key wasn't already known to the kernel when it
|
||||
was requested.
|
||||
This is the actual content of a key.
|
||||
This is usually set when a key is created,
|
||||
but it is possible for the kernel to upcall to userspace to finish the
|
||||
instantiation of a key if that key wasn't already known to the kernel
|
||||
when it was requested.
|
||||
.IP
|
||||
A key's payload can be read and updated if the key type supports it and if
|
||||
suitable permission is granted to the caller.
|
||||
.IP "\fBAccess rights\fR"
|
||||
Each key has an owning user ID, an owning group and a security label - much as
|
||||
files do. They also have a set of permissions, though there are more than for
|
||||
a normal UNIX file, and there is an additional category beyond the usual user,
|
||||
files do.
|
||||
They also have a set of permissions,
|
||||
though there are more than for a normal UNIX file,
|
||||
and there is an additional category beyond the usual user,
|
||||
group and other (see below).
|
||||
.IP
|
||||
Note that keys are quota controlled since they represent unswappable kernel
|
||||
memory and the owning user ID specifies whose quota is to be debited.
|
||||
.IP "\fBExpiration time\fR"
|
||||
Each key can have an expiration time set. When that time is reached, the key
|
||||
is marked as being expired and accesses to it fail with \fIEKEYEXPIRED\fR. If
|
||||
not deleted, updated or replaced, after a set amount of time, expired keys are
|
||||
Each key can have an expiration time set.
|
||||
When that time is reached,
|
||||
the key is marked as being expired and accesses to it fail with
|
||||
\fIEKEYEXPIRED\fR.
|
||||
If not deleted, updated or replaced, after a set amount of time,
|
||||
expired keys are
|
||||
automatically removed along with all links to them and \fIENOKEY\fR will be
|
||||
reported.
|
||||
.IP "\fBReference count\fR"
|
||||
Each key has a reference count. Keys are referenced by keyrings, by current
|
||||
active users and by a process's credentials. When the reference count reaches
|
||||
zero, the key is scheduled for garbage collection.
|
||||
Each key has a reference count.
|
||||
Keys are referenced by keyrings, by current active users
|
||||
and by a process's credentials.
|
||||
When the reference count reaches zero,
|
||||
the key is scheduled for garbage collection.
|
||||
.P
|
||||
See the
|
||||
.BR keyctl_describe (3)
|
||||
|
|
@ -104,19 +114,22 @@ manual page for more information.
|
|||
.P
|
||||
The facility provides several basic types of key:
|
||||
.IP "\fBkeyring\fR"
|
||||
Keys of this type are special. The payload consists of a set of links to other
|
||||
keys, analogous to a directory holding links to files. The main purpose of a
|
||||
keyring is to prevent other keys from being garbage collected because nothing
|
||||
refers to them.
|
||||
Keys of this type are special.
|
||||
The payload consists of a set of links to other
|
||||
keys, analogous to a directory holding links to files.
|
||||
The main purpose of a keyring is to prevent other keys from
|
||||
being garbage collected because nothing refers to them.
|
||||
.IP "\fBuser\fR"
|
||||
This is a general purpose key type. It may be instantiated with an arbitrary
|
||||
blob of data of up to about 32KB. It is kept entirely within kernel memory.
|
||||
This is a general purpose key type.
|
||||
It may be instantiated with an arbitrary blob of data of up to about 32KB.
|
||||
It is kept entirely within kernel memory.
|
||||
It may be read and updated by userspace.
|
||||
.IP "\fBbig_key\fR"
|
||||
This is similar to \fBuser\fR but it may hold data up to 1MB in size. The data
|
||||
may be stored in the swap space rather than in kernel memory if the size
|
||||
exceeds the overhead of doing so (a tmpfs file is used - which requires
|
||||
filesystem structures to be allocated in the kernel).
|
||||
This is similar to \fBuser\fR but it may hold data up to 1MB in size.
|
||||
The data may be stored in the swap space rather than in kernel memory
|
||||
if the size exceeds the overhead of doing so
|
||||
(a tmpfs file is used - which requires filesystem structures
|
||||
to be allocated in the kernel).
|
||||
.IP "\fBlogon\fR"
|
||||
This is similar to \fBuser\fR but the contents may not be read by userspace.
|
||||
.P
|
||||
|
|
@ -126,27 +139,30 @@ here as they're not intended for normal userspace use.
|
|||
.P
|
||||
.SH KEYRINGS
|
||||
As previously mentioned, keyrings are a special type of key that contain links
|
||||
to other keys (which may include other keyrings). Keys may be linked to by
|
||||
multiple keyrings. Keyrings may be considered as analogous to UNIX directories
|
||||
to other keys (which may include other keyrings).
|
||||
Keys may be linked to by multiple keyrings.
|
||||
Keyrings may be considered as analogous to UNIX directories
|
||||
where each directory contains a set of hard links to files.
|
||||
.P
|
||||
Several of the syscall functions available may only be applied to keyrings:
|
||||
.IP "\fBAdding\fR"
|
||||
A key may be added to a keyring by system calls that create keys. This
|
||||
prevents the new key from being immediately deleted when the system call driver
|
||||
releases its last reference to the key.
|
||||
A key may be added to a keyring by system calls that create keys.
|
||||
This prevents the new key from being immediately deleted
|
||||
when the system call driver releases its last reference to the key.
|
||||
.IP "\fBLinking\fR"
|
||||
A link may be added to a keyring pointing to a key that is already known,
|
||||
provided this does not create a self-referential cycle.
|
||||
.IP "\fBUnlinking\fR"
|
||||
A link may be removed from a keyring. When the last link to a key is removed,
|
||||
A link may be removed from a keyring.
|
||||
When the last link to a key is removed,
|
||||
that key will be scheduled for deletion by the garbage collector.
|
||||
.IP "\fBClearing\fR"
|
||||
All the links may be removed from a keyring.
|
||||
.IP "\fBSearching\fR"
|
||||
A keyring may be considered the root of a tree or subtree in which keyrings
|
||||
form the branches and non-keyrings the leaves. This tree may be searched for a
|
||||
leaf matching a particular type and description.
|
||||
form the branches and non-keyrings the leaves.
|
||||
This tree may be searched for a leaf matching
|
||||
a particular type and description.
|
||||
.P
|
||||
See the
|
||||
.BR keyctl_clear (3),
|
||||
|
|
@ -158,42 +174,45 @@ manual pages for more information.
|
|||
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
.SH ANCHORING KEYS
|
||||
.P
|
||||
To prevent a key from being prematurely garbage collected, it must anchored to
|
||||
keep its reference count elevated when it is not in active use by the kernel.
|
||||
To prevent a key from being prematurely garbage collected,
|
||||
it must anchored to keep its reference count elevated
|
||||
when it is not in active use by the kernel.
|
||||
.P
|
||||
\fBKeyrings\fR are used to anchor other keys - each link is a reference on a
|
||||
key - but whilst keyrings are available to link to keys, keyrings themselves
|
||||
are just keys and are also subject to the same anchoring necessity.
|
||||
.P
|
||||
The kernel makes available a number of anchor keyrings. Note that some of
|
||||
these keyrings will only be created when first accessed.
|
||||
The kernel makes available a number of anchor keyrings.
|
||||
Note that some of these keyrings will only be created when first accessed.
|
||||
.IP "\fBProcess keyrings\fR"
|
||||
Process credentials themselves reference keyrings with specific semantics.
|
||||
These keyrings are pinned as long as the set of credentials exists - which is
|
||||
usually as long as the process does.
|
||||
.IP
|
||||
There are three keyrings with different inheritance/sharing rules: The \fBsession
|
||||
keyring\fR (inherited and shared by all child processes), the \fBprocess keyring\fR
|
||||
(shared by all threads in a process) and the \fBthread keyring\fR (specific to
|
||||
a particular thread).
|
||||
There are three keyrings with different inheritance/sharing rules:
|
||||
The \fBsession keyring\fR (inherited and shared by all child processes),
|
||||
the \fBprocess keyring\fR (shared by all threads in a process) and
|
||||
the \fBthread keyring\fR (specific to a particular thread).
|
||||
.IP "\fBUser keyrings\fR"
|
||||
Each UID known to the kernel has a record that contains two keyrings: The
|
||||
\fBuser keyring\fR and the \fBuser session keyring\fR. These exist for as long
|
||||
as the UID record in the kernel exists. A link to the user keyring is placed
|
||||
in a new session keyring by \fBpam_keyinit\fR when a new login session is
|
||||
initiated.
|
||||
\fBuser keyring\fR and the \fBuser session keyring\fR.
|
||||
These exist for as long as the UID record in the kernel exists.
|
||||
A link to the user keyring is placed in a new session keyring by
|
||||
\fBpam_keyinit\fR when a new login session is initiated.
|
||||
.IP "\fBPersistent keyrings\fR"
|
||||
There is a \fBpersistent keyring\fR available to each UID known to the system.
|
||||
It may persist beyond the life of the UID record previously mentioned, but has
|
||||
an expiration time set such that it is automatically cleaned up after a set
|
||||
time. This, for example, permits cron scripts to use credentials left when the
|
||||
It may persist beyond the life of the UID record previously mentioned,
|
||||
but has an expiration time set such that it is automatically cleaned up
|
||||
after a set time.
|
||||
This, for example, permits cron scripts to use credentials left when the
|
||||
user logs out.
|
||||
.IP
|
||||
Note that the expiration time is reset every time the persistent key is
|
||||
requested.
|
||||
.IP "\fBSpecial keyrings\fR"
|
||||
There are special keyrings owned by the kernel that can anchor keys for special
|
||||
purposes. An example of this is the \fBsystem keyring\fR used for holding
|
||||
There are special keyrings owned by the kernel that can anchor keys
|
||||
for special purposes.
|
||||
An example of this is the \fBsystem keyring\fR used for holding
|
||||
encryption keys for module signature verification.
|
||||
.IP
|
||||
These are usually closed to direct alteration by userspace.
|
||||
|
|
@ -211,8 +230,8 @@ manual pages for more information.
|
|||
.SH POSSESSION
|
||||
.P
|
||||
The concept of '\fBpossession\fR' is important to understanding the keyrings
|
||||
security model. Whether a thread possesses a key is determined by the
|
||||
following rules:
|
||||
security model.
|
||||
Whether a thread possesses a key is determined by the following rules:
|
||||
.IP (1)
|
||||
Any key or keyring that does not grant \fBSearch\fP permission to the caller is
|
||||
\fIignored\fP in all the following rules.
|
||||
|
|
@ -229,11 +248,12 @@ If a process is upcalled from the kernel to instantiate a key, then it also
|
|||
possess's the \fIrequester's\fP keyrings as in rule (1) as if it were the
|
||||
requester.
|
||||
.P
|
||||
Note that possession is not a fundamental property of a key, but must rather be
|
||||
calculated each time it is needed.
|
||||
Note that possession is not a fundamental property of a key,
|
||||
but must rather be calculated each time it is needed.
|
||||
.P
|
||||
Possession is designed to allow setuid programs run from, say, a user's shell
|
||||
to access the user's keys. It also allows the prevention of access to keys
|
||||
to access the user's keys.
|
||||
It also allows the prevention of access to keys
|
||||
just on the basis of UID and GID matches.
|
||||
.P
|
||||
When it creates the session keyring, the \fBpam_keyinit\fR module adds a link
|
||||
|
|
@ -256,7 +276,8 @@ Each key has the following security-related attributes:
|
|||
.P
|
||||
The permissions mask is used to govern the following rights:
|
||||
.IP \fBView\fR
|
||||
If set, the attributes of a key may be read. This includes the type,
|
||||
If set, the attributes of a key may be read.
|
||||
This includes the type,
|
||||
description and access rights (excluding the security label).
|
||||
.IP \fBRead\fR
|
||||
If set, the payload of a key may be read and a list of the serial numbers to
|
||||
|
|
@ -268,15 +289,16 @@ from a keyring, a keyring may be cleared completely and a key may be revoked.
|
|||
If set, keyrings and subkeyrings may be searched and keys and keyrings may be
|
||||
found by that search.
|
||||
.IP \fBLink\fR
|
||||
If set, an additional link may be made to a key from a keyring. The initial
|
||||
link to a key when it is created doesn't require this permit.
|
||||
If set, an additional link may be made to a key from a keyring.
|
||||
The initial link to a key when it is created doesn't require this permit.
|
||||
.IP \fBSetattr\fR
|
||||
If set, the ownership details on a key and its security label may be changed,
|
||||
its expiration time may be set and it may be revoked.
|
||||
.P
|
||||
The permissions mask contains four sets of rights. The first three sets are
|
||||
mutually exclusive. One and only one will be in force at any one time. In
|
||||
order of descending priority:
|
||||
The permissions mask contains four sets of rights.
|
||||
The first three sets are mutually exclusive.
|
||||
One and only one will be in force at any one time.
|
||||
In order of descending priority:
|
||||
.IP \fBUser\fR
|
||||
Used if the key's user ID matches the caller's \fBfsuid\fR.
|
||||
.IP \fBGroup\fR
|
||||
|
|
@ -289,15 +311,18 @@ The fourth set of rights is:
|
|||
.IP \fBPossessor\fR
|
||||
Used if a key is determined to be \fBpossessed\fR by the caller.
|
||||
.P
|
||||
The complete set of rights for a key is the set union of whichever of the first
|
||||
three sets is selected plus the fourth if the key is possessed.
|
||||
The complete set of rights for a key is the set union of whichever
|
||||
of the first three sets is selected plus the fourth
|
||||
if the key is possessed.
|
||||
.P
|
||||
If any right is granted to a thread for a key, then that thread will see the
|
||||
key listed in /proc/keys. If no rights at all are granted, then that thread
|
||||
key listed in /proc/keys.
|
||||
If no rights at all are granted, then that thread
|
||||
can't even tell that the key exists.
|
||||
.P
|
||||
In addition to access rights, any active \fBLinux Security Module\fP may
|
||||
prevent access to a key if its policy so dictates. A key may be given a
|
||||
prevent access to a key if its policy so dictates.
|
||||
A key may be given a
|
||||
security label or other attribute by the LSM which can be retrieved.
|
||||
.P
|
||||
See the
|
||||
|
|
@ -312,9 +337,10 @@ manual pages for more information.
|
|||
.SH SEARCHING FOR KEYS
|
||||
.P
|
||||
One of the key features of this facility is the ability to find a key that it
|
||||
is retaining. The \fBrequest_key\fR() system call is the primary point of
|
||||
access for userspace to find a key to use (the kernel has something similar
|
||||
available).
|
||||
is retaining.
|
||||
The \fBrequest_key\fR() system call is the primary point of
|
||||
access for userspace to find a key to use
|
||||
(the kernel has something similar available).
|
||||
.P
|
||||
The search algorithm works as follows:
|
||||
.IP (1)
|
||||
|
|
@ -335,8 +361,8 @@ key is returned.
|
|||
If a matching key is found that has an error state attached, that error state
|
||||
is noted and the search continues.
|
||||
.IP (6)
|
||||
If valid matching key is found, then the first noted error state is returned or
|
||||
else \fBENOKEY\fR is returned.
|
||||
If valid matching key is found,
|
||||
then the first noted error state is returned or else \fBENOKEY\fR is returned.
|
||||
.P
|
||||
It is also possible to search a specific keyring, in which case only steps (3)
|
||||
to (6) apply.
|
||||
|
|
@ -351,14 +377,16 @@ manual pages for more information.
|
|||
.P
|
||||
If a key cannot be found, the \fBrequest_key\fR() system call will, if given a
|
||||
\fIcallout_info\fR argument, create a new key and then upcall to userspace to
|
||||
instantiate the key. This allows keys to be created on an as-needed basis.
|
||||
instantiate the key.
|
||||
This allows keys to be created on an as-needed basis.
|
||||
.P
|
||||
Typically, this will involve the kernel forking and exec'ing \fBrequest-key\fR
|
||||
program, which will then execute the appopriate handler based on its
|
||||
configuration.
|
||||
.P
|
||||
The handler is passed a special authorisation key that allows it and only it to
|
||||
instantiate the new key. This is also used to permit searches performed by the
|
||||
instantiate the new key.
|
||||
This is also used to permit searches performed by the
|
||||
handler program to also search the requester's keyrings.
|
||||
.P
|
||||
See the
|
||||
|
|
@ -383,15 +411,16 @@ The kernel uses the upcall mechanism provided by the keys to upcall to
|
|||
userspace to do DNS lookups and then to cache the results.
|
||||
.IP "\fBAF_RXRPC and kAFS - Authentication\fR"
|
||||
The AF_RXRPC network protocol and the in-kernel AFS filesystem store the ticket
|
||||
needed to do secured or encrypted traffic in keys. These are then looked up by
|
||||
needed to do secured or encrypted traffic in keys.
|
||||
These are then looked up by
|
||||
network operations on AF_RXRPC and filesystem operations on kAFS.
|
||||
.IP "\fBNFS - User ID mapping\fR"
|
||||
The NFS filesystem uses keys to store foreign user ID to local user ID mapping.
|
||||
.IP "\fBCIFS - Password\fR"
|
||||
The CIFS filesystem uses keys to store passwords for accessing remote shares.
|
||||
.IP "\fBModule verification\fR"
|
||||
The kernel build process can be made to cryptographically sign modules. That
|
||||
signature is then checked when a module is loaded.
|
||||
The kernel build process can be made to cryptographically sign modules.
|
||||
That signature is then checked when a module is loaded.
|
||||
.P
|
||||
Userspace users of this facility include:
|
||||
.IP "\fBKerberos key storage\fR"
|
||||
|
|
|
|||
|
|
@ -16,12 +16,13 @@ persistent-keyring \- per-user persistent keyring
|
|||
.SH DESCRIPTION
|
||||
The
|
||||
.B persistent keyring
|
||||
is a keyring used to anchor keys on behalf of a user. Each UID the kernel
|
||||
deals with has its own persistent keyring that is shared between all threads
|
||||
owned by that UID.
|
||||
is a keyring used to anchor keys on behalf of a user.
|
||||
Each UID the kernel deals with has its own persistent keyring that
|
||||
is shared between all threads owned by that UID.
|
||||
.P
|
||||
The persistent keyring is created on demand when a thread requests it. The
|
||||
keyring's expiration timer is reset every time it is accessed to the value in:
|
||||
The persistent keyring is created on demand when a thread requests it.
|
||||
The keyring's expiration timer is reset every time it is accessed
|
||||
to the value in:
|
||||
.IP
|
||||
/proc/sys/kernel/keys/persistent_keyring_expiry
|
||||
.P
|
||||
|
|
@ -29,13 +30,17 @@ The persistent keyring is not searched by \fBrequest_key\fP() unless it is
|
|||
referred to by a keyring that is.
|
||||
.P
|
||||
The persistent keyring may not be accessed directly, even by processes with
|
||||
the appropriate UID. Instead it must be linked to one of a process's keyrings
|
||||
the appropriate UID.
|
||||
Instead it must be linked to one of a process's keyrings
|
||||
first before that keyring can access it by virtue of its possessor permits.
|
||||
This is done with \fBkeyctl_get_persistent\fP().
|
||||
.P
|
||||
Persistent keyrings are independent of clone(), fork(), vfork(), execve() and
|
||||
exit(). They persist until their expiration timers trigger - at which point
|
||||
they are garbage collected. This allows them to carry keys beyond the life of
|
||||
Persistent keyrings are independent of
|
||||
clone(), fork(), vfork(), execve() and
|
||||
exit().
|
||||
They persist until their expiration timers trigger - at which point
|
||||
they are garbage collected.
|
||||
This allows them to carry keys beyond the life of
|
||||
the kernel's record of the corresponding UID (the destruction of which results
|
||||
in the destruction of the user and user session keyrings).
|
||||
.P
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ process-keyring \- per-process shared keyring
|
|||
.SH DESCRIPTION
|
||||
The
|
||||
.B process keyring
|
||||
is a keyring used to anchor keys on behalf of a process. It is only created
|
||||
when a process requests it.
|
||||
is a keyring used to anchor keys on behalf of a process.
|
||||
It is only created when a process requests it.
|
||||
.P
|
||||
A special serial number value, \fBKEY_SPEC_PROCESS_KEYRING\fP, is defined that
|
||||
can be used in lieu of the calling process's process keyring's actual serial
|
||||
|
|
@ -28,7 +28,8 @@ much the same way, but as keyctl is a program run after forking, this is of no
|
|||
utility.
|
||||
.P
|
||||
A process's process keyring is inherited across clone() with CLONE_THREAD and
|
||||
is cleared by execve(). The process keyring will be destroyed when the last
|
||||
is cleared by execve().
|
||||
The process keyring will be destroyed when the last
|
||||
thread that refers to it exits.
|
||||
.P
|
||||
If a process doesn't have a process keyring when it is accessed, then the
|
||||
|
|
|
|||
|
|
@ -16,8 +16,9 @@ session-keyring \- session shared process keyring
|
|||
.SH DESCRIPTION
|
||||
The
|
||||
.B session keyring
|
||||
is a keyring used to anchor keys on behalf of a process. It is typically
|
||||
created by the \fBpam_keyinit\fP module when a user logs in and a link will be
|
||||
is a keyring used to anchor keys on behalf of a process.
|
||||
It is typically created by the \fBpam_keyinit\fP module
|
||||
when a user logs in and a link will be
|
||||
added that refers to the \fBuser keyring\fP.
|
||||
.P
|
||||
A special serial number value, \fBKEY_SPEC_SESSION_KEYRING\fP, is defined that
|
||||
|
|
@ -29,7 +30,8 @@ much the same way.
|
|||
.P
|
||||
A process's session keyring is inherited across clone(), fork() and vfork() and
|
||||
is retained across execve() - even when the target executable is setuid or
|
||||
setgid. The session keyring will be destroyed when the last process that
|
||||
setgid.
|
||||
The session keyring will be destroyed when the last process that
|
||||
refers to it exits.
|
||||
.P
|
||||
If a process doesn't have a session keyring when it is accessed, then, under
|
||||
|
|
@ -39,12 +41,14 @@ session keyring and under others a new session keyring will be created.
|
|||
The keyutils library provides a number of special operations for manipulating
|
||||
session keyrings:
|
||||
.IP \fBkeyctl_join_session_keyring\fP()
|
||||
This operation allows the caller to change their session keyring. The caller
|
||||
can join an existing keyring by name, create a new keyring of the name given or
|
||||
This operation allows the caller to change their session keyring.
|
||||
The caller can join an existing keyring by name,
|
||||
create a new keyring of the name given or
|
||||
ask the kernel to create a new session keyring with the name "_ses".
|
||||
.IP \fBkeyctl_session_to_parent\fP()
|
||||
This operation allows the caller to set the parent process's session keyring to
|
||||
the same as their own. For this to succeed, the parent process must have
|
||||
the same as their own.
|
||||
For this to succeed, the parent process must have
|
||||
identical security attributes and must be single threaded.
|
||||
.P
|
||||
These operations are also exposed through the keyctl utility as:
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ thread-keyring \- per-thread keyring
|
|||
.SH DESCRIPTION
|
||||
The
|
||||
.B thread keyring
|
||||
is a keyring used to anchor keys on behalf of a process. It is only created
|
||||
when a thread requests it.
|
||||
is a keyring used to anchor keys on behalf of a process.
|
||||
It is only created when a thread requests it.
|
||||
.P
|
||||
A special serial number value, \fBKEY_SPEC_THREAD_KEYRING\fP, is defined that
|
||||
can be used in lieu of the calling thread's thread keyring's actual serial
|
||||
|
|
|
|||
|
|
@ -16,15 +16,18 @@ user-keyring \- per-user keyring
|
|||
.SH DESCRIPTION
|
||||
The
|
||||
.B user keyring
|
||||
is a keyring used to anchor keys on behalf of a user. Each UID the kernel
|
||||
deals with has its own user keyring. This keyring is associated with the
|
||||
record that the kernel maintains for the UID and, once created, is retained as
|
||||
long as that record persists. It is shared amongst all processes of that UID.
|
||||
is a keyring used to anchor keys on behalf of a user.
|
||||
Each UID the kernel deals with has its own user keyring.
|
||||
This keyring is associated with the record that the kernel maintains
|
||||
for the UID and, once created, is retained as long as that record persists.
|
||||
It is shared amongst all processes of that UID.
|
||||
.P
|
||||
The user keyring is created on demand when a thread requests it. Normally,
|
||||
The user keyring is created on demand when a thread requests it.
|
||||
Normally,
|
||||
this happens when \fBpam_keyinit\fP is invoked when a user logs in.
|
||||
.P
|
||||
The user keyring is not searched by default by \fBrequest_key\fP(). When the
|
||||
The user keyring is not searched by default by \fBrequest_key\fP().
|
||||
When the
|
||||
pam_keyinit module creates a session keyring, it adds to it a link to the user
|
||||
keyring so that the user keyring will be searched when the session keyring is.
|
||||
.P
|
||||
|
|
|
|||
|
|
@ -16,15 +16,19 @@ user-session-keyring \- per-user default session keyring
|
|||
.SH DESCRIPTION
|
||||
The
|
||||
.B user session keyring
|
||||
is a keyring used to anchor keys on behalf of a user. Each UID the kernel
|
||||
deals with has its own user session keyring. This keyring is associated with
|
||||
is a keyring used to anchor keys on behalf of a user.
|
||||
Each UID the kernel
|
||||
deals with has its own user session keyring.
|
||||
This keyring is associated with
|
||||
the record that the kernel maintains for the UID and, once created, is retained
|
||||
as long as that record persists. It is shared amongst all processes of that
|
||||
as long as that record persists.
|
||||
It is shared amongst all processes of that
|
||||
UID.
|
||||
.P
|
||||
The user session keyring is created on demand when a thread requests it or when
|
||||
a thread asks for its \fBsession keyring\fP and that doesn't exist. In the
|
||||
latter case, a user session keyring will be created and, if the session keyring
|
||||
The user session keyring is created on demand when a thread requests it
|
||||
or when a thread asks for its \fBsession keyring\fP and that doesn't exist.
|
||||
In the latter case,
|
||||
a user session keyring will be created and, if the session keyring
|
||||
wasn't to be created, the user session keyring will be set as the process's
|
||||
actual session keyring.
|
||||
.P
|
||||
|
|
|
|||
Loading…
Reference in New Issue