요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
=========================================
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: https://tools.ietf.org/rfc/rfc2203.txt
- RFC5403 v2: https://tools.ietf.org/rfc/rfc5403.txt
There is a third version that we don't currently implement:
- RFC7861 v3: https://tools.ietf.org/rfc/rfc7861.txt
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 fundamentally 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.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Kernel RPC server의 RPCGSS 표준 범위
1-19이 문서는 NFS server와 NFS client의 NFSv4.0 callback server 같은 kernel RPC server에서 RPCGSS authentication을 구현할 때 사용하는 표준과 protocol을 안내합니다.
NFSv4.1 이상에서는 authentication 목적으로 client가 server 역할을 할 필요가 없다는 차이가 있습니다.
RPCGSS version 1은 RFC 2203, version 2는 RFC 5403에 정의되어 있습니다. RFC 7861의 version 3도 존재하지만 현재 Linux 구현은 지원하지 않습니다.
문서가 다루는 version과 현재 구현 범위입니다.
=========================================
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: https://tools.ietf.org/rfc/rfc2203.txt
- RFC5403 v2: https://tools.ietf.org/rfc/rfc5403.txt
There is a third version that we don't currently implement:
- RFC7861 v3: https://tools.ietf.org/rfc/rfc7861.txt
GSSAPI 작업의 kernel/user-space 분리
20-45RPCGSS authentication method는 NFS에서 GSSAPI authentication을 수행하는 방법을 정의합니다. GSSAPI 자체는 mechanism-neutral이지만 많은 NFS 구현은 `KRB5` mechanism만 지원합니다.
현재 Linux kernel도 `KRB5`만 지원하며 KRB5-specific GSSAPI extension에 의존합니다.
GSSAPI 전체를 kernel에 구현하기에는 library가 복잡하고 필요성도 낮습니다. GSSAPI operation은 initial context establishment와 개별 packet의 integrity/privacy protection, 즉 signing과 encryption의 두 부분으로 나눌 수 있습니다.
Context establishment는 더 복잡하고 policy와 독립적이지만 성능 민감도는 낮습니다. Packet별 protection은 더 단순하지만 매우 빨라야 합니다.
따라서 Linux는 packet별 integrity와 privacy protection을 kernel에서 수행하고 initial context establishment는 user space에 맡깁니다. Kernel은 upcall로 user space에 context establishment를 요청합니다.
복잡도와 성능 민감도에 따라 실행 위치를 나눕니다.
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 fundamentally 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.
rpc.svcgssd text upcall의 크기 제한
46-66고전적인 NFS server upcall은 `nfs-utils` package의 custom daemon `rpc.svcgssd`와 통신하는 custom text protocol입니다.
첫 제한은 token 크기가 2 KiB를 넘을 수 없다는 점입니다. 일부 Kerberos 배포에서는 ticket에 붙은 여러 authorization extension 때문에 context establishment에 필요한 GSSAPI token이 64 KiB 이상으로 커질 수 있습니다.
둘째 제한은 kernel로 돌려보낼 수 있는 buffer가 4 KiB라서 사용자가 수천 개보다 많은 group에 속한 credential을 제대로 처리하지 못한다는 점입니다. 현재 kernel의 hard limit은 group 65K개입니다.
Text transport의 두 buffer 한계입니다.
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).
gss-proxy RPC upcall
67-79새 upcall mechanism은 Unix socket 위의 RPC를 사용해 `gss-proxy` daemon과 통신합니다. Daemon은 user-space program `Gssproxy`가 구현합니다.
`gss_proxy` RPC protocol은 원문이 연결한 GSS Proxy protocol documentation에 설명되어 있습니다.
Kernel RPC client가 일반 Unix socket으로 gssproxy user-space program에 연결하며, 이 protocol은 legacy text protocol의 token·response size 제한을 갖지 않습니다.
Kernel RPC client가 Unix socket을 통해 context establishment를 위임합니다.
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.
Upcall mechanism 선택 순서
80-93Backward compatibility를 위해 kernel 기본값은 legacy mechanism입니다. 새 mechanism으로 바꾸려면 gss-proxy가 먼저 `/var/run/gssproxy.sock`에 bind하고 `/proc/net/rpc/use-gss-proxy`에 `1`을 써야 합니다.
gss-proxy process가 죽으면 socket bind와 control-file write 두 단계를 모두 다시 수행해야 합니다.
한 번 선택한 upcall mechanism은 바꿀 수 없습니다. Legacy에 고정되는 것을 막으려면 위 절차를 nfsd 시작 전에 끝내야 합니다.
Nfsd를 시작하는 process는 `/proc/net/rpc/use-gss-proxy`를 읽어 값이 `1`인지 확인할 수 있습니다. 이 read는 gss-proxy가 file에 값을 쓸 때까지 block하므로 올바른 startup ordering을 보장합니다.
Nfsd 전에 새 mechanism 선택을 확정해야 합니다.
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.
요약·해설
rpc-server-gss.rst:1-93Linux kernel RPC server는 KRB5 기반 RPCGSS에서 복잡한 initial context establishment를 user space에 맡기고, 성능에 민감한 packet signing·encryption은 kernel에서 수행합니다.
Legacy `rpc.svcgssd` text upcall은 2 KiB token과 4 KiB response 제한이 있습니다. `gss-proxy` RPC/Unix-socket mechanism은 이 제한을 없애지만 nfsd 시작 전에 socket bind와 control-file write를 완료해 선택을 고정해야 합니다.
두 mechanism의 transport와 startup 특성입니다.