Section: Maintenance Commands (8)
Updated: 20 Feb 2013Index
Return to Main Contents
rpc.gssd - RPCSEC_GSS daemon
The RPCSEC_GSS protocol, defined in RFC 5403, is used to provide
strong security for RPC-based protocols such as NFS.
Before exchanging RPC requests using RPCSEC_GSS, an RPC client must
establish a GSS
A security context is shared state on each
end of a network transport that enables GSS-API security services.
Security contexts are established using
A credential grants temporary access to a secure network service,
much as a railway ticket grants temporary access to use a rail service.
A user typically obtains a credential by providing a password to the
command, or via a PAM library at login time.
A credential acquired with a
is known as a
for more on principals).
For certain operations, a credential is required
which represents no user,
is otherwise unprivileged,
and is always available.
This is referred to as a
Machine credentials are typically established using a
whose encrypted password, called its
is stored in a file, called a
to avoid requiring a user prompt.
A machine credential effectively does not expire because the system
can renew it as needed without user intervention.
Once obtained, credentials are typically stored in local temporary files
with well-known pathnames.
To establish GSS security contexts using these credential files,
the Linux kernel RPC client depends on a userspace daemon called
daemon uses the rpc_pipefs filesystem to communicate with the kernel.
When a user authenticates using a command such as
the resulting credential is stored in a file with a well-known name
constructed using the user's UID.
To interact with an NFS server
on behalf of a particular Kerberos-authenticated user,
the Linux kernel RPC client requests that
initialize a security context with the credential
in that user's credential file.
Typically, credential files are placed in
can search for credential files in more than one directory.
See the description of the
option for details.
A user credential is established by a user and
is then shared with the kernel and
A machine credential is established by
for the kernel when there is no user.
must already have the materials on hand to establish this credential
without requiring user intervention.
searches the local system's keytab for a principal and key to use
to establish the machine credential.
assumes the file
contains principals and keys that can be used to obtain machine credentials.
searches in the following order for a principal to use.
The first matching credential is used.
For the search, <hostname> and <REALM> are replaced with the local
system's hostname and Kerberos realm.
The <anyname> entries match on the service name and realm, but ignore the hostname.
These can be used if a principal matching the local host's name is not found.
Note that the first principal in the search order is a user principal
that enables Kerberized NFS when the local system is joined
to an Active Directory domain using Samba.
A password for this principal must be provided in the local system's keytab.
You can specify another keytab by using the
does not exist or does not provide one of these principals.
Credentials for UID 0
UID 0 is a special case.
uses the system's machine credentials for UID 0 accesses
that require GSS authentication.
This limits the privileges of the root user
when accessing network resources that require authentication.
option when starting
if you'd like to force the root user to obtain a user credential
rather than use the local system's machine credential.
the kernel continues to request a GSS context established
with a machine credential for NFSv4 operations,
such as SETCLIENTID or RENEW, that manage state.
cannot obtain a machine credential (say, the local system has
no keytab), NFSv4 operations that require machine credentials will fail.
A realm administrator can choose to add keys encoded in a number of different
encryption types to the local system's keytab.
For instance, a host/ principal might have keys for the
to choose an appropriate encryption type that the target NFS server
These encryption types are stronger than legacy single-DES encryption types.
To interoperate in environments where servers support
only weak encryption types,
you can restrict your client to use only single-DES encryption types
by specifying the
option when starting
DNS Reverse lookups are not used for determining the
server names pass to GSSAPI. This option will reverses that and forces
the use of DNS Reverse resolution of the server's IP address to
retrieve the server name to use in GSAPI authentication.
in the foreground and sends output to stderr (as opposed to syslogd)
When specified, UID 0 is forced to obtain user credentials
which are used instead of the local system's machine credentials.
- -k keytab
to use the keys found in
to obtain machine credentials.
The default value is
When specified, restricts
to sessions to weak encryption types such as
This option is available only when the local system's Kerberos library
supports settable encryption types.
- -p path
where to look for the rpc_pipefs filesystem. The default value is
- -d search-path
This option specifies a colon separated list of directories that
searches for credential files. The default value is
The literal sequence "%U" can be specified to substitue the UID
of the user for whom credentials are being searched.
By default, machine credentials are stored in files in the first
directory in the credential directory search path (see the
stores machine credentials in memory instead.
Increases the verbosity of the output (can be specified multiple times).
If the RPCSEC_GSS library supports setting debug level,
increases the verbosity of the output (can be specified multiple times).
- -R realm
Kerberos tickets from this
will be preferred when scanning available credentials cache files to be
used to create a context. By default, the default realm, as configured
in the Kerberos configuration file, is preferred.
- -t timeout
Timeout, in seconds, for kernel GSS contexts. This option allows you to force
new kernel contexts to be negotiated after
seconds, which allows changing Kerberos tickets and identities frequently.
The default is no explicit timeout, which means the kernel context will live
the lifetime of the Kerberos service ticket used in its creation.
Dug Song <firstname.lastname@example.org
Andy Adamson <email@example.com
Marius Aamodt Eriksen <firstname.lastname@example.org
J. Bruce Fields <email@example.com
- User Credentials
- Machine Credentials
- Credentials for UID 0
- Encryption types
- SEE ALSO