mirror of https://github.com/mkerrisk/man-pages
add_key.2, bpf.2, fcntl.2, futex.2, listxattr.2, perf_event_open.2, prctl.2, request_key.2, sigaltstack.2, __ppc_set_ppr_med.3, __ppc_yield.3, getw.3, setbuf.3, setjmp.3, lirc.4, core.5, securetty.5, inode.7, keyrings.7, process-keyring.7, user-keyring.7, ld.so.8: srcfix: use .PP instead of .P
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk
parent
dd3568a147
commit
11ac5b5109
|
|
@ -36,10 +36,10 @@ of length
|
|||
attaches it to the nominated
|
||||
.IR keyring ,
|
||||
and returns the key's serial number.
|
||||
.P
|
||||
.PP
|
||||
The key may be rejected if the provided data is in the wrong format or
|
||||
it is invalid in some other way.
|
||||
.P
|
||||
.PP
|
||||
If the destination
|
||||
.I keyring
|
||||
already contains a key that matches the specified
|
||||
|
|
@ -57,7 +57,7 @@ and it will displace the link to the extant key from the keyring.
|
|||
.\" is consequently unlinked, then keys that it was anchoring
|
||||
.\" will have their reference count decreased by one (and may
|
||||
.\" consequently be garbage collected). Is this all correct?
|
||||
.P
|
||||
.PP
|
||||
The destination
|
||||
.I keyring
|
||||
serial number may be that of a valid keyring for which the caller has
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ the original ("classic") BPF (cBPF) used to filter network packets.
|
|||
For both cBPF and eBPF programs,
|
||||
the kernel statically analyzes the programs before loading them,
|
||||
in order to ensure that they cannot harm the running system.
|
||||
.P
|
||||
.PP
|
||||
eBPF extends cBPF in multiple ways, including the ability to call
|
||||
a fixed set of in-kernel helper functions
|
||||
.\" See 'enum bpf_func_id' in include/uapi/linux/bpf.h
|
||||
|
|
@ -79,7 +79,7 @@ If a map lookup fails, the current program continues its execution.
|
|||
See
|
||||
.B BPF_MAP_TYPE_PROG_ARRAY
|
||||
below for further details.
|
||||
.P
|
||||
.PP
|
||||
Generally, eBPF programs are loaded by the user process and automatically
|
||||
unloaded when the process exits.
|
||||
In some cases, for example,
|
||||
|
|
|
|||
10
man2/fcntl.2
10
man2/fcntl.2
|
|
@ -403,7 +403,7 @@ If the conflicting lock is an open file description lock, then
|
|||
is set to \-1.
|
||||
Note that the returned information
|
||||
may already be out of date by the time the caller inspects it.
|
||||
.P
|
||||
.PP
|
||||
In order to place a read lock,
|
||||
.I fd
|
||||
must be open for reading.
|
||||
|
|
@ -438,12 +438,12 @@ deadlock-detection algorithm; see BUGS.
|
|||
As well as being removed by an explicit
|
||||
.BR F_UNLCK ,
|
||||
record locks are automatically released when the process terminates.
|
||||
.P
|
||||
.PP
|
||||
Record locks are not inherited by a child created via
|
||||
.BR fork (2),
|
||||
but are preserved across an
|
||||
.BR execve (2).
|
||||
.P
|
||||
.PP
|
||||
Because of the buffering performed by the
|
||||
.BR stdio (3)
|
||||
library, the use of record locking with routines in that package
|
||||
|
|
@ -1064,7 +1064,7 @@ other open file descriptors for the file.
|
|||
.B F_UNLCK
|
||||
Remove our lease from the file.
|
||||
.RE
|
||||
.P
|
||||
.PP
|
||||
Leases are associated with an open file description (see
|
||||
.BR open (2)).
|
||||
This means that duplicate file descriptors (created by, for example,
|
||||
|
|
@ -1077,7 +1077,7 @@ Furthermore, the lease is released by either an explicit
|
|||
.B F_UNLCK
|
||||
operation on any of these duplicate file descriptors, or when all
|
||||
such file descriptors have been closed.
|
||||
.P
|
||||
.PP
|
||||
Leases may be taken out only on regular files.
|
||||
An unprivileged process may take out a lease only on a file whose
|
||||
UID (owner) matches the filesystem UID of the process.
|
||||
|
|
|
|||
|
|
@ -984,7 +984,7 @@ Additionally,
|
|||
(or the error
|
||||
.B EINVAL
|
||||
results).
|
||||
.P
|
||||
.PP
|
||||
The PI futex operations are as follows:
|
||||
.\"
|
||||
.\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ user.name1\\0system.name1\\0user.name2\\0
|
|||
.fi
|
||||
.RE
|
||||
.fam T
|
||||
.P
|
||||
.PP
|
||||
Filesystems that implement POSIX ACLs using
|
||||
extended attributes might return a
|
||||
.I list
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ event periodically writes measurements to a buffer that can then
|
|||
be accessed via
|
||||
.BR mmap (2).
|
||||
.SS Arguments
|
||||
.P
|
||||
.PP
|
||||
The
|
||||
.I pid
|
||||
and
|
||||
|
|
@ -105,7 +105,7 @@ value of less than 1.
|
|||
.TP
|
||||
.BR "pid == \-1" " and " "cpu == \-1"
|
||||
This setting is invalid and will return an error.
|
||||
.P
|
||||
.PP
|
||||
When
|
||||
.I pid
|
||||
is greater than zero, permission to perform this system call
|
||||
|
|
@ -135,7 +135,7 @@ This means that the values of the member events can be
|
|||
meaningfully compared\(emadded, divided (to get ratios), and so on\(emwith each
|
||||
other, since they have counted events for the same set of executed
|
||||
instructions.
|
||||
.P
|
||||
.PP
|
||||
The
|
||||
.I flags
|
||||
argument is formed by ORing together zero or more of the following values:
|
||||
|
|
@ -194,7 +194,7 @@ must be passed as the
|
|||
parameter.
|
||||
cgroup monitoring is available only
|
||||
for system-wide events and may therefore require extra permissions.
|
||||
.P
|
||||
.PP
|
||||
The
|
||||
.I perf_event_attr
|
||||
structure provides detailed configuration information
|
||||
|
|
@ -546,7 +546,7 @@ value use the following equation:
|
|||
(perf_hw_cache_id) | (perf_hw_cache_op_id << 8) |
|
||||
(perf_hw_cache_op_result_id << 16)
|
||||
.fi
|
||||
.P
|
||||
.PP
|
||||
where
|
||||
.I perf_hw_cache_id
|
||||
is one of:
|
||||
|
|
@ -574,7 +574,7 @@ for measuring the branch prediction unit
|
|||
.\" commit 89d6c0b5bdbb1927775584dcf532d98b3efe1477
|
||||
for measuring local memory accesses
|
||||
.RE
|
||||
.P
|
||||
.PP
|
||||
and
|
||||
.I perf_hw_cache_op_id
|
||||
is one of:
|
||||
|
|
@ -589,7 +589,7 @@ for write accesses
|
|||
.B PERF_COUNT_HW_CACHE_OP_PREFETCH
|
||||
for prefetch accesses
|
||||
.RE
|
||||
.P
|
||||
.PP
|
||||
and
|
||||
.I perf_hw_cache_op_result_id
|
||||
is one of:
|
||||
|
|
@ -1248,7 +1248,7 @@ Branch target is in hypervisor.
|
|||
.TP
|
||||
.B PERF_SAMPLE_BRANCH_PLM_ALL
|
||||
A convenience value that is the three preceding values ORed together.
|
||||
.P
|
||||
.PP
|
||||
In addition to the privilege value, at least one or more of the
|
||||
following bits must be set.
|
||||
.TP
|
||||
|
|
@ -2192,7 +2192,7 @@ The branch was in an aborted transactional memory transaction.
|
|||
.\" commit 71ef3c6b9d4665ee7afbbe4c208a98917dcfc32f
|
||||
This reports the number of cycles elapsed since the
|
||||
previous branch stack update.
|
||||
.P
|
||||
.PP
|
||||
The entries are from most to least recent, so the first entry
|
||||
has the most recent branch.
|
||||
.PP
|
||||
|
|
|
|||
|
|
@ -596,7 +596,7 @@ value.
|
|||
The requirements for the address are the same as for the
|
||||
.BR PR_SET_MM_START_BRK
|
||||
option.
|
||||
.P
|
||||
.PP
|
||||
The following options are available since Linux 3.5.
|
||||
.\" commit fe8c7f5cbf91124987106faa3bdf0c8b955c4cf7
|
||||
.TP
|
||||
|
|
@ -658,7 +658,7 @@ in a process life time.
|
|||
Any further attempts will be rejected.
|
||||
This should help system administrators monitor unusual
|
||||
symbolic-link transitions over all processes running on a system.
|
||||
.P
|
||||
.PP
|
||||
The following options are available since Linux 3.18.
|
||||
.\" commit f606b77f1a9e362451aca8f81d8f36a3a112139e
|
||||
.TP
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ first recursively searches for a matching key in all of the keyrings
|
|||
attached to the calling process.
|
||||
The keyrings are searched in the order: thread-specific keyring,
|
||||
process-specific keyring, and then session keyring.
|
||||
.P
|
||||
.PP
|
||||
If
|
||||
.BR request_key ()
|
||||
is called from a program invoked by
|
||||
|
|
@ -53,7 +53,7 @@ supplementary group IDs, and security context to determine access.
|
|||
.\" David Howells: we can then have an arbitrarily long sequence
|
||||
.\" of "recursive" request-key upcalls. There is no limit, other
|
||||
.\" than number of PIDs, etc.
|
||||
.P
|
||||
.PP
|
||||
The search of the keyring tree is breadth-first:
|
||||
the keys in each keyring searched are checked for a match before any child
|
||||
keyrings are recursed into.
|
||||
|
|
@ -62,7 +62,7 @@ Only keys for which the caller has
|
|||
permission be found, and only keyrings for which the caller has
|
||||
.I search
|
||||
permission may be searched.
|
||||
.P
|
||||
.PP
|
||||
If the key is not found and
|
||||
.I callout
|
||||
is NULL, then the call fails with the error
|
||||
|
|
@ -342,7 +342,7 @@ At this point, the
|
|||
.BR request_key ()
|
||||
call completes, and the requesting program can continue execution.
|
||||
.RE
|
||||
.P
|
||||
.PP
|
||||
If these steps are unsuccessful, then an
|
||||
.BR ENOKEY
|
||||
error will be returned to the caller of
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ When establishing a signal handler using
|
|||
inform the system that the signal handler should be executed
|
||||
on the alternate signal stack by
|
||||
specifying the \fBSA_ONSTACK\fP flag.
|
||||
.P
|
||||
.PP
|
||||
The \fIss\fP argument is used to specify a new
|
||||
alternate signal stack, while the \fIold_ss\fP argument
|
||||
is used to retrieve information about the currently
|
||||
|
|
@ -192,7 +192,7 @@ normal process stack is exhausted: in this case, a signal handler for
|
|||
.B SIGSEGV
|
||||
cannot be invoked on the process stack; if we wish to handle it,
|
||||
we must use an alternate signal stack.
|
||||
.P
|
||||
.PP
|
||||
Establishing an alternate signal stack is useful if a process
|
||||
expects that it may exhaust its standard stack.
|
||||
This may occur, for example, because the stack grows so large
|
||||
|
|
@ -202,13 +202,13 @@ If the standard stack is exhausted, the kernel sends
|
|||
the process a \fBSIGSEGV\fP signal.
|
||||
In these circumstances the only way to catch this signal is
|
||||
on an alternate signal stack.
|
||||
.P
|
||||
.PP
|
||||
On most hardware architectures supported by Linux, stacks grow
|
||||
downward.
|
||||
.BR sigaltstack ()
|
||||
automatically takes account
|
||||
of the direction of stack growth.
|
||||
.P
|
||||
.PP
|
||||
Functions called from a signal handler executing on an alternate
|
||||
signal stack will also use the alternate signal stack.
|
||||
(This also applies to any handlers invoked for other signals while
|
||||
|
|
@ -217,7 +217,7 @@ Unlike the standard stack, the system does not
|
|||
automatically extend the alternate signal stack.
|
||||
Exceeding the allocated size of the alternate signal stack will
|
||||
lead to unpredictable results.
|
||||
.P
|
||||
.PP
|
||||
A successful call to
|
||||
.BR execve (2)
|
||||
removes any existing alternate
|
||||
|
|
@ -225,7 +225,7 @@ signal stack.
|
|||
A child process created via
|
||||
.BR fork (2)
|
||||
inherits a copy of its parent's alternate signal stack settings.
|
||||
.P
|
||||
.PP
|
||||
.BR sigaltstack ()
|
||||
supersedes the older
|
||||
.BR sigstack ()
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Set the Program Priority Register
|
|||
These functions provide access to the
|
||||
.I Program Priority Register
|
||||
(PPR) on the Power architecture.
|
||||
.P
|
||||
.PP
|
||||
The PPR is a 64-bit register that controls the program's priority.
|
||||
By adjusting the PPR value the programmer may improve system
|
||||
throughput by causing system resources to be used more
|
||||
|
|
@ -66,7 +66,7 @@ sets the Program Priority Register value to
|
|||
.BR __ppc_set_ppr_med_low ()
|
||||
sets the Program Priority Register value to
|
||||
.IR "medium low" .
|
||||
.P
|
||||
.PP
|
||||
The privileged state
|
||||
.IR "medium high"
|
||||
may also be set during certain time intervals by problem-state (unprivileged)
|
||||
|
|
@ -75,7 +75,7 @@ programs, with the following function:
|
|||
.BR __ppc_set_ppr_med_high ()
|
||||
sets the Program Priority to
|
||||
.IR "medium high" .
|
||||
.P
|
||||
.PP
|
||||
If the program priority is medium high when the time interval expires or if an
|
||||
attempt is made to set the priority to medium high when it is not allowed, the
|
||||
priority is set to medium.
|
||||
|
|
|
|||
|
|
@ -41,18 +41,18 @@ provide hints about the usage of resources that are shared with other
|
|||
processors on the Power architecture.
|
||||
They can be used, for example, if a program waiting on a lock intends
|
||||
to divert the shared resources to be used by other processors.
|
||||
.P
|
||||
.PP
|
||||
.BR __ppc_yield ()
|
||||
provides a hint that performance will probably be improved if shared
|
||||
resources dedicated to the executing processor are released for use by
|
||||
other processors.
|
||||
.P
|
||||
.PP
|
||||
.BR __ppc_mdoio ()
|
||||
provides a hint that performance will probably be improved if shared
|
||||
resources dedicated to the executing processor are released until all
|
||||
outstanding storage accesses to caching-inhibited storage have been
|
||||
completed.
|
||||
.P
|
||||
.PP
|
||||
.BR __ppc_mdoom ()
|
||||
provides a hint that performance will probably be improved if shared
|
||||
resources dedicated to the executing processor are released until all
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ It's provided for compatibility with SVr4.
|
|||
We recommend you use
|
||||
.BR fread (3)
|
||||
instead.
|
||||
.P
|
||||
.PP
|
||||
.BR putw ()
|
||||
writes the word \fIw\fP (that is,
|
||||
an \fIint\fP) to \fIstream\fP.
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ functions conform to C89 and C99.
|
|||
.\" On 4.2BSD and 4.3BSD systems,
|
||||
.\" .BR setbuf ()
|
||||
.\" always uses a suboptimal buffer size and should be avoided.
|
||||
.P
|
||||
.PP
|
||||
You must make sure that the space that
|
||||
.I buf
|
||||
points to still exists by the time
|
||||
|
|
|
|||
|
|
@ -235,7 +235,7 @@ and
|
|||
.IP \(bu
|
||||
they are not declared as
|
||||
.IR volatile .
|
||||
.P
|
||||
.PP
|
||||
Analogous remarks apply for
|
||||
.BR siglongjmp ().
|
||||
.\"
|
||||
|
|
|
|||
34
man4/lirc.4
34
man4/lirc.4
|
|
@ -24,14 +24,14 @@
|
|||
.SH NAME
|
||||
lirc \- lirc devices
|
||||
.SH DESCRIPTION
|
||||
.P
|
||||
.PP
|
||||
The
|
||||
.B /dev/lirc*
|
||||
character devices provide a low-level
|
||||
bi-directional interface to infra-red (IR) remotes.
|
||||
When receiving data, the driver works in two different modes depending
|
||||
on the underlying hardware.
|
||||
.P
|
||||
.PP
|
||||
Some hardware (typically TV-cards) decodes the IR signal internally
|
||||
and just provides decoded button presses as integer values.
|
||||
Drivers for this kind of hardware work in
|
||||
|
|
@ -40,7 +40,7 @@ mode.
|
|||
Such hardware usually does not support sending IR signals.
|
||||
Furthermore, it usually only works with a specific remote which is
|
||||
bundled with, for example, a TV-card.
|
||||
.P
|
||||
.PP
|
||||
Other hardware provides a stream of pulse/space durations.
|
||||
Such drivers work in
|
||||
.BR LIRC_MODE_MODE2
|
||||
|
|
@ -48,12 +48,12 @@ mode.
|
|||
Sometimes, this kind of hardware also supports
|
||||
sending IR data.
|
||||
Such hardware can be used with (almost) any kind of remote.
|
||||
.P
|
||||
.PP
|
||||
The \fBLIRC_GET_REC_MODE\fR ioctl (see below) allows probing for the
|
||||
mode.
|
||||
.\"
|
||||
.SS Reading input with the LIRC_MODE_MODE2 drivers
|
||||
.P
|
||||
.PP
|
||||
In the \fBLIRC_MODE_MODE2 mode\fR, the data returned by
|
||||
.BR read (2)
|
||||
provides 32-bit values representing a space or a pulse duration, by
|
||||
|
|
@ -81,7 +81,7 @@ ioctl.
|
|||
.SS Reading input with the
|
||||
.B LIRC_MODE_LIRCCODE
|
||||
drivers
|
||||
.P
|
||||
.PP
|
||||
In the \fBLIRC_MODE_LIRCCODE\fR
|
||||
mode, the data returned by
|
||||
.BR read (2)
|
||||
|
|
@ -93,7 +93,7 @@ the bit count returned by the \fBLIRC_GET_LENGTH\fR ioctl, rounded
|
|||
up so it matches full bytes.
|
||||
.\"
|
||||
.SS Sending data
|
||||
.P
|
||||
.PP
|
||||
When sending data, only the \fBLIRC_MODE_PULSE\fR
|
||||
mode is supported.
|
||||
The data written to the character device using
|
||||
|
|
@ -112,30 +112,30 @@ call fails with the error
|
|||
.BR EINVAL
|
||||
.\"
|
||||
.SH IOCTL COMMANDS
|
||||
.P
|
||||
.PP
|
||||
The complete list of ioctl commands is maintained in the kernel
|
||||
documentation, see SEE ALSO.
|
||||
The ioctl commands presented here is a subset of the kernel
|
||||
documentation.
|
||||
.P
|
||||
.PP
|
||||
The LIRC device's ioctl definition is bound by the ioctl function
|
||||
definition of struct file_operations, leaving us with an unsigned
|
||||
int for the ioctl command and an unsigned long for the argument.
|
||||
For the purposes of ioctl portability across 32-bit and 64-bit architectures,
|
||||
these values are capped to their 32-bit sizes.
|
||||
.P
|
||||
.PP
|
||||
.nf
|
||||
#include <lirc/include/media/lirc.h> /* But see BUGS */
|
||||
int ioctl(int fd, int cmd, ...);
|
||||
.fi
|
||||
.P
|
||||
.PP
|
||||
The following ioctls can be used to probe or change specific lirc
|
||||
hardware settings.
|
||||
Many require a third argument, usually an
|
||||
.IR int .
|
||||
referred to below as
|
||||
.IR val .
|
||||
.P
|
||||
.PP
|
||||
In general, each driver should have a default set of settings.
|
||||
The driver implementation is expected to re-apply the default settings
|
||||
when the device is closed by user space, so that every application
|
||||
|
|
@ -143,7 +143,7 @@ opening the device can rely on working with the default settings
|
|||
initially.
|
||||
.\"
|
||||
.SS Always Supported Commands
|
||||
.P
|
||||
.PP
|
||||
\fI/dev/lirc*\fR devices always support the following commands:
|
||||
.TP 4
|
||||
.BR LIRC_GET_FEATURES " (\fIvoid\fP)"
|
||||
|
|
@ -165,13 +165,13 @@ The driver returns a sequence of pulse/space durations.
|
|||
The driver returns integer values, each of which represents a decoded
|
||||
button press.
|
||||
.RE
|
||||
.P
|
||||
.PP
|
||||
If a device returns an error code for
|
||||
.BR LIRC_GET_REC_MODE ,
|
||||
it is safe to assume it is not a lirc device.
|
||||
.\"
|
||||
.SS Optional Commands
|
||||
.P
|
||||
.PP
|
||||
Some lirc devices support commands listed below.
|
||||
Unless otherwise stated, these fail with the error \fBENOIOCTLCMD\fR
|
||||
or with the error \fBENOSYS\fR if the operation
|
||||
|
|
@ -371,7 +371,7 @@ This can be used by supporting hardware to give visual user
|
|||
feedback, for example by flashing an LED.
|
||||
.\"
|
||||
.SH FEATURES
|
||||
.P
|
||||
.PP
|
||||
The features returned by
|
||||
The
|
||||
.BR LIRC_GET_FEATURES
|
||||
|
|
@ -471,5 +471,5 @@ Users of older kernels could use the file bundled in
|
|||
.\"
|
||||
.SH SEE ALSO
|
||||
.BR lircd (8)
|
||||
.P
|
||||
.PP
|
||||
https://www.kernel.org/doc/htmldocs/media_api/lirc_dev.html
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ TID of thread that triggered core dump, as seen in the initial PID namespace
|
|||
PID of dumped process,
|
||||
as seen in the PID namespace in which the process resides
|
||||
.TP
|
||||
%P
|
||||
.PP
|
||||
.\" Added in git commit 65aafb1e7484b7434a0c1d4c593191ebe5776a2f
|
||||
PID of dumped process, as seen in the initial PID namespace
|
||||
(since Linux 3.12)
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ contains the names of terminals
|
|||
.IR /dev/ )
|
||||
which are considered secure for the transmission of certain authentication
|
||||
tokens.
|
||||
.P
|
||||
.PP
|
||||
It is used by (some versions of)
|
||||
.BR login (1)
|
||||
to restrict the terminals
|
||||
|
|
@ -42,7 +42,7 @@ on which root is allowed to login.
|
|||
See
|
||||
.BR login.defs (5)
|
||||
if you use the shadow suite.
|
||||
.P
|
||||
.PP
|
||||
On PAM enabled systems, it is used for the same purpose by
|
||||
.BR pam_securetty (8)
|
||||
to restrict the terminals on which empty passwords are accepted.
|
||||
|
|
|
|||
|
|
@ -373,7 +373,7 @@ S_IWOTH 00002 others have write permission
|
|||
S_IXOTH 00001 others have execute permission
|
||||
.TE
|
||||
.in
|
||||
.P
|
||||
.PP
|
||||
The set-group-ID bit
|
||||
.RB ( S_ISGID )
|
||||
has several special uses.
|
||||
|
|
@ -387,7 +387,7 @@ For a file that does not have the group execution bit
|
|||
.RB ( S_IXGRP )
|
||||
set,
|
||||
the set-group-ID bit indicates mandatory file/record locking.
|
||||
.P
|
||||
.PP
|
||||
The sticky bit
|
||||
.RB ( S_ISVTX )
|
||||
on a directory means that a file
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ The Linux key-management facility
|
|||
is primarily a way for various kernel components
|
||||
to retain or cache security data,
|
||||
authentication keys, encryption keys, and other data in the kernel.
|
||||
.P
|
||||
.PP
|
||||
System call interfaces are provided so that user-space programs can manage
|
||||
those objects and also use the facility for their own purposes; see
|
||||
.BR add_key (2),
|
||||
|
|
@ -175,7 +175,7 @@ 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
|
||||
where each directory contains a set of hard links to files.
|
||||
.P
|
||||
.PP
|
||||
Various operations (system calls) may be applied only to keyrings:
|
||||
.IP Adding
|
||||
A key may be added to a keyring by system calls that create keys.
|
||||
|
|
@ -195,7 +195,7 @@ 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 key matching
|
||||
a particular type and description.
|
||||
.P
|
||||
.PP
|
||||
See
|
||||
.BR keyctl_clear (3),
|
||||
.BR keyctl_link (3),
|
||||
|
|
@ -326,16 +326,16 @@ If a process is upcalled from the kernel to instantiate a key (see
|
|||
.BR request_key (2)),
|
||||
then it also possesses the requester's keyrings as in
|
||||
rule (1) as if it were the requester.
|
||||
.P
|
||||
.PP
|
||||
Note that possession is not a fundamental property of a key,
|
||||
but must rather be calculated each time the key is needed.
|
||||
.P
|
||||
.PP
|
||||
Possession is designed to allow set-user-ID programs run from, say
|
||||
a user's shell to access the user's keys.
|
||||
Granting permissions to the key possessor while denying them
|
||||
to the key owner and group allows the prevention of access to keys
|
||||
on the basis of UID and GID matches.
|
||||
.P
|
||||
.PP
|
||||
When it creates the session keyring,
|
||||
.BR pam_keyinit (8)
|
||||
adds a link to the
|
||||
|
|
@ -352,7 +352,7 @@ The ID of a group that is permitted to access the key
|
|||
A security label
|
||||
.IP *
|
||||
A permissions mask
|
||||
.P
|
||||
.PP
|
||||
The permissions mask contains four sets of rights.
|
||||
The first three sets are mutually exclusive.
|
||||
One and only one will be in force for a particular access check.
|
||||
|
|
@ -367,16 +367,16 @@ filesystem GID or one of the caller's supplementary group IDs.
|
|||
.IP \fIother\fR
|
||||
The set specifies the rights granted
|
||||
if neither the key's user ID nor group ID matched.
|
||||
.P
|
||||
.PP
|
||||
The fourth set of rights is:
|
||||
.IP \fIpossessor\fR
|
||||
The set specifies the rights granted
|
||||
if a key is determined to be possessed by the caller.
|
||||
.P
|
||||
.PP
|
||||
The complete set of rights for a key is the union of whichever
|
||||
of the first three sets is applicable plus the fourth set
|
||||
if the key is possessed.
|
||||
.P
|
||||
.PP
|
||||
The set of rights that may be granted in each of the four masks
|
||||
is as follows:
|
||||
.TP
|
||||
|
|
@ -408,14 +408,14 @@ doesn't require this permission.
|
|||
.I setattr
|
||||
The ownership details and security label of the key may be changed,
|
||||
the key's expiration time may be set, and the key may be revoked.
|
||||
.P
|
||||
.PP
|
||||
In addition to access rights, any active Linux Security Module (LSM) may
|
||||
prevent access to a key if its policy so dictates.
|
||||
A key may be given a
|
||||
security label or other attribute by the LSM;
|
||||
this label is retrievable via
|
||||
.BR keyctl_get_security (3).
|
||||
.P
|
||||
.PP
|
||||
See
|
||||
.BR keyctl_chown (3),
|
||||
.BR keyctl_describe (3),
|
||||
|
|
@ -434,7 +434,7 @@ system call is the primary point of
|
|||
access for user-space applications to find a key.
|
||||
(Internally, the kernel has something similar available
|
||||
for use by internal components that make use of keys.)
|
||||
.P
|
||||
.PP
|
||||
The search algorithm works as follows:
|
||||
.IP (1) 4
|
||||
The process keyrings are searched in the following order: the thread
|
||||
|
|
@ -467,10 +467,10 @@ If no valid matching key is found,
|
|||
then the first noted error state is returned; otherwise, an
|
||||
.B ENOKEY
|
||||
error is returned.
|
||||
.P
|
||||
.PP
|
||||
It is also possible to search a specific keyring, in which case only steps
|
||||
(3) to (6) apply.
|
||||
.P
|
||||
.PP
|
||||
See
|
||||
.BR request_key (2)
|
||||
and
|
||||
|
|
@ -485,18 +485,18 @@ will, if given a
|
|||
argument, create a new key and then upcall to user space to
|
||||
instantiate the key.
|
||||
This allows keys to be created on an as-needed basis.
|
||||
.P
|
||||
.PP
|
||||
Typically,
|
||||
this will involve the kernel creating a new process that executes the
|
||||
.BR request-key (8)
|
||||
program, which will then execute the appropriate handler based on its
|
||||
configuration.
|
||||
.P
|
||||
.PP
|
||||
The handler is passed a special authorization key that allows it
|
||||
and only it to instantiate the new key.
|
||||
This is also used to permit searches performed by the
|
||||
handler program to also search the requester's keyrings.
|
||||
.P
|
||||
.PP
|
||||
See
|
||||
.BR request_key (2),
|
||||
.BR keyctl_assume_authority (3),
|
||||
|
|
@ -814,7 +814,7 @@ note that each link in a keyring consumes 4 bytes of the keyring payload.
|
|||
.SS Users
|
||||
The Linux key-management facility has a number of users and usages,
|
||||
but is not limited to those that already exist.
|
||||
.P
|
||||
.PP
|
||||
In-kernel users of this facility include:
|
||||
.TP
|
||||
Network filesystems - DNS
|
||||
|
|
@ -837,7 +837,7 @@ The CIFS filesystem uses keys to store passwords for accessing remote shares.
|
|||
Module verification
|
||||
The kernel build process can be made to cryptographically sign modules.
|
||||
That signature is then checked when a module is loaded.
|
||||
.P
|
||||
.PP
|
||||
User-space users of this facility include:
|
||||
.TP
|
||||
Kerberos key storage
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ The process keyring is a keyring used to anchor keys on behalf of a process.
|
|||
It is created only when a process requests it.
|
||||
The process keyring has the name (description)
|
||||
.IR _pid .
|
||||
.P
|
||||
.PP
|
||||
A special serial number value,
|
||||
.BR KEY_SPEC_PROCESS_KEYRING ,
|
||||
is defined that can be used in lieu of the actual serial number of
|
||||
|
|
|
|||
|
|
@ -64,14 +64,14 @@ and
|
|||
.BR _exit (2)
|
||||
excepting that the keyring is destroyed when the UID record is destroyed when
|
||||
the last process pinning it exits.
|
||||
.P
|
||||
.PP
|
||||
If it is necessary for a key associated with a user to exist beyond the UID
|
||||
record being garbage collected\(emfor example, for use by a
|
||||
.BR cron (8)
|
||||
script\(emthen the
|
||||
.BR persistent-keyring (7)
|
||||
should be used instead.
|
||||
.P
|
||||
.PP
|
||||
If a user keyring does not exist when it is accessed, it will be created.
|
||||
.SH SEE ALSO
|
||||
.ad l
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ to the dynamic linker can be passed and, in the ELF case, the dynamic linker
|
|||
which is stored in the
|
||||
.B .interp
|
||||
section of the program is executed) or directly by running:
|
||||
.P
|
||||
.PP
|
||||
.I /lib/ld\-linux.so.*
|
||||
[OPTIONS] [PROGRAM [ARGUMENTS]]
|
||||
.SH DESCRIPTION
|
||||
|
|
|
|||
Loading…
Reference in New Issue