1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
NFS/RPC with more than 16 groups per user
=========================================
The patch is useful when users are member of more than 16 groups on a
Linux NFS client. The patch bypasses this protocol imposed limit in a
compatible manner (i.e. no server patching).
All patches are distributed under the GNU General Public License.
For details, see the COPYING file (copied from the Linux source).
Theory of operation
===================
NFS is based on RPC. RPC comes in a number of flavors. The patch deals
with SUNRPC based on AUTH_UNIX authentication, a popular authentication
flavor for NFS. The NFS client has to tell the server who is doing an
operation and the server will do the permission checking. The identity is
composed of euid (fsuid), egid and the secondary group list. The latter
will be truncated to 16 groups by RPC and that's where NFS breaks.
Linux 2.4.x has a standard limit of 32 groups (like most other UNIces)
and these are already too many for NFS. Some sysadmins would even like to
raise the limit well beyond 32, for example 256 groups per user. If you
want to do that, change limits.h and asm/param.h and recompile kernel,
glibc and shadow-utils. Linux 2.6.x has a limit of 65536 groups which
seems enough in most cases :). But now onto NFS:
It is fairly simple to predict the group id's which might make a difference
in an operation on NFS on the client system, assuming the NFS server does
permission checking conform UNIX. This is not a bad assumption when NFS
uses RPC with AUTH_UNIX authentication. Pathnames at system call time
are not handled in one NFS operation (NFS != WebNFS) but by a series
of NFS lookups. Therefor the maximum number of groups required at any
specific point in time is 3 at most: see nfs_rename().
Patch version 3.x
=================
The patch maintains a cache of the 16 most recently used group id's. This
cache is updated before executing the NFS operation. The cache is kept
sorted by group number because the RPC layer compares group lists when
it looks for a matching credential in its own cache. The purpose of the
cache is not to "guess groups" or something but to prepare for so-called
short credentials which could reduce network bandwidth. That hasn't
been investigated any further.
Patch version 4.x
=================
Group id cache is gone. At the top NFS layer the group ids of
"interesting" file-system objects are collected (max 3, mostly 1) and
passed downwards. When an RPC credential is created the new AUTH_UNIX
specific unx_add_groups() function will add all the necessary group
information. When the number of groups is 16 or lower then it reverts
to old behavior. When there is no group id information passed downwards
then it reverts to old behavior too. Otherwise, only groups present in
_both_ group information passed downwards and the secondary group list
will be used for the AUTH_UNIX rpc credential (i.e. group lists are
intersected).
The patch has become significantly larger, mostly due to restructuring
and some cleanups:
- removed broken_suid mount option (merged in 2.6.12)
- reduced the number of rpc_message instantiations.
NOTES
-----
- The NFS server should not do subtree checking: on linux,
this requires the "no_subtree_check" option in /etc/exports
- Only NFS v2 and v3. v4 is not affected.
BUG REPORTS
-----------
If you think something didn't work as expected then it would be
helpful if you mail it and possibly include a relevant section of
/var/log/messages after reproducing the problem with
echo 16 >/proc/sys/sunrpc/rpc_debug
echo 17 >/proc/sys/sunrpc/nfs_debug
It is probably best to try to reproduce the problem with the "noac"
mount option.
TODO
----
- See 2.6.12/README#TODO
- patch on top of http://www.linux-nfs.org/ <latest>
- unx_add_groups() may result in duplicate gids. ok?
- nfs_idmap_new(): id mapping?
Changelog
=========
2005-06-26 nfs-ngroups 4.54 for 2.6.12
2005-06-13 nfs-ngroups 4.54 for 2.6.12-rc6
- avoid partially working feature for NFSv4: it could cause confusion.
2005-03-06 nfs-ngroups 4.53 for 2.6.11
2005-02-14 nfs-ngroups 4.53 for 2.6.11-rc4
- fixed CONFIG_NFSD_V4 compilation breakage.
2005-02-12 nfs-ngroups 4.52 for 2.6.11-rc4
2005-02-07 nfs-ngroups 4.52 for 2.6.11-rc3
2005-02-07 nfs-ngroups 4.52 for 2.6.10
- fixed SETATTR: need another gid for truncate.
- added some debug
2005-02-04 nfs-ngroups 4.51 for 2.6.10
- fixed SETATTR: need gid for chown(new gid)
2005-02-03 nfs-ngroups 4.50 for 2.6.10
- It compiles but hasn't been tested.
2002-05-26 nfs-ngroups 3.98 for 2.4.19-pre8
- fixed "too many groups" warnings. They were false alarm caused
by not allocating the group id cache when the group is equal
to fsgid.
- fixed sys_setgroups16(). Ouch. Appearently I missed the introduction
of the 16/32 bit uid/gid split.
|
