Documentation: nfs: rpc-server-gss: convert to ReST
Convert rpc-server-gss.txt to ReST. Content remains mostly unchanged. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Link: https://lore.kernel.org/r/20200129044917.566906-4-dwlsalmeida@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:

committed by
Jonathan Corbet

parent
f0bf8a988b
commit
250baf06aa
94
Documentation/filesystems/nfs/rpc-server-gss.rst
Normal file
94
Documentation/filesystems/nfs/rpc-server-gss.rst
Normal file
@@ -0,0 +1,94 @@
|
||||
=========================================
|
||||
rpcsec_gss support for kernel RPC servers
|
||||
=========================================
|
||||
|
||||
This document gives references to the standards and protocols used to
|
||||
implement RPCGSS authentication in kernel RPC servers such as the NFS
|
||||
server and the NFS client's NFSv4.0 callback server. (But note that
|
||||
NFSv4.1 and higher don't require the client to act as a server for the
|
||||
purposes of authentication.)
|
||||
|
||||
RPCGSS is specified in a few IETF documents:
|
||||
|
||||
- RFC2203 v1: http://tools.ietf.org/rfc/rfc2203.txt
|
||||
- RFC5403 v2: http://tools.ietf.org/rfc/rfc5403.txt
|
||||
|
||||
and there is a 3rd version being proposed:
|
||||
|
||||
- http://tools.ietf.org/id/draft-williams-rpcsecgssv3.txt
|
||||
(At draft n. 02 at the time of writing)
|
||||
|
||||
Background
|
||||
==========
|
||||
|
||||
The RPCGSS Authentication method describes a way to perform GSSAPI
|
||||
Authentication for NFS. Although GSSAPI is itself completely mechanism
|
||||
agnostic, in many cases only the KRB5 mechanism is supported by NFS
|
||||
implementations.
|
||||
|
||||
The Linux kernel, at the moment, supports only the KRB5 mechanism, and
|
||||
depends on GSSAPI extensions that are KRB5 specific.
|
||||
|
||||
GSSAPI is a complex library, and implementing it completely in kernel is
|
||||
unwarranted. However GSSAPI operations are fundementally separable in 2
|
||||
parts:
|
||||
|
||||
- initial context establishment
|
||||
- integrity/privacy protection (signing and encrypting of individual
|
||||
packets)
|
||||
|
||||
The former is more complex and policy-independent, but less
|
||||
performance-sensitive. The latter is simpler and needs to be very fast.
|
||||
|
||||
Therefore, we perform per-packet integrity and privacy protection in the
|
||||
kernel, but leave the initial context establishment to userspace. We
|
||||
need upcalls to request userspace to perform context establishment.
|
||||
|
||||
NFS Server Legacy Upcall Mechanism
|
||||
==================================
|
||||
|
||||
The classic upcall mechanism uses a custom text based upcall mechanism
|
||||
to talk to a custom daemon called rpc.svcgssd that is provide by the
|
||||
nfs-utils package.
|
||||
|
||||
This upcall mechanism has 2 limitations:
|
||||
|
||||
A) It can handle tokens that are no bigger than 2KiB
|
||||
|
||||
In some Kerberos deployment GSSAPI tokens can be quite big, up and
|
||||
beyond 64KiB in size due to various authorization extensions attacked to
|
||||
the Kerberos tickets, that needs to be sent through the GSS layer in
|
||||
order to perform context establishment.
|
||||
|
||||
B) It does not properly handle creds where the user is member of more
|
||||
than a few thousand groups (the current hard limit in the kernel is 65K
|
||||
groups) due to limitation on the size of the buffer that can be send
|
||||
back to the kernel (4KiB).
|
||||
|
||||
NFS Server New RPC Upcall Mechanism
|
||||
===================================
|
||||
|
||||
The newer upcall mechanism uses RPC over a unix socket to a daemon
|
||||
called gss-proxy, implemented by a userspace program called Gssproxy.
|
||||
|
||||
The gss_proxy RPC protocol is currently documented `here
|
||||
<https://fedorahosted.org/gss-proxy/wiki/ProtocolDocumentation>`_.
|
||||
|
||||
This upcall mechanism uses the kernel rpc client and connects to the gssproxy
|
||||
userspace program over a regular unix socket. The gssproxy protocol does not
|
||||
suffer from the size limitations of the legacy protocol.
|
||||
|
||||
Negotiating Upcall Mechanisms
|
||||
=============================
|
||||
|
||||
To provide backward compatibility, the kernel defaults to using the
|
||||
legacy mechanism. To switch to the new mechanism, gss-proxy must bind
|
||||
to /var/run/gssproxy.sock and then write "1" to
|
||||
/proc/net/rpc/use-gss-proxy. If gss-proxy dies, it must repeat both
|
||||
steps.
|
||||
|
||||
Once the upcall mechanism is chosen, it cannot be changed. To prevent
|
||||
locking into the legacy mechanisms, the above steps must be performed
|
||||
before starting nfsd. Whoever starts nfsd can guarantee this by reading
|
||||
from /proc/net/rpc/use-gss-proxy and checking that it contains a
|
||||
"1"--the read will block until gss-proxy has done its write to the file.
|
Reference in New Issue
Block a user