File: README

package info (click to toggle)
kernel-patch-nfs-ngroups 3.98-15
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 136 kB
  • ctags: 1
  • sloc: makefile: 24
file content (57 lines) | stat: -rw-r--r-- 2,570 bytes parent folder | download
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
These patches are distributed under the GNU General Public License.
For details, see the COPYING file (copied from the Linux 2.4.x 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, the most popular flavor
for NFS I guess. 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 has a standard limit of 32 groups (like most other UNIces) and
this is 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. 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().

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.

NFS is stateless. Therefor the group id cache is _not_ updated for I/O
operations but at nfs_open() time.


Changelog
---------

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.


Open issues
-----------
-	redesign to use exactly those groups necessary and not maintaining a
	cache anymore. Short credentials are the only reason to maintain the
	cache and it doesn't look they're going to be implemented really soon.
-	Other authentication flavours.