Why does NFS suppress group-write permission?

[Guy Harris]

>Well, maybe it doesn't,

It doesn't.  Perhaps the implementations you were using did, but the
last two implementations I tried it on (Sun-4/280 running SunOS 4.0.3,
Auspex NS5000 running Auspex 1.1/SunOS 4.0.3) didn't.

>A search of TFM turned up nary a hint that NFS would do such a nasty
>thing to us.  But the evidence is too strong to be coincidence.  I 
>suspect that there is either code in nfsd to explicitly do this, or 
>nfsd always runs with its umask set to 022, and since it (not the user) 
>is *really* the one that creates the file (i.e., makes the open() system 
>call), its umask gets used instead of the correct one.

It may be that the servers on the systems on which you tried it had
their umask set to 022; however, a quick look at the NFSSRC4.0 source
from Sun - the "reference port" upon which a lot of UNIX NFS
implementations are based, and which is itself derived from the SunOS
4.0 source (and 4.3BSD source), reveals that the umask is used at the
*system call* level, not inside the file system, and that the NFS server
code doesn't go through the system call level so the umask of an NFS
server process is irrelevant.  (I.e., "nfsd" doesn't make an "open()"
system call, it calls the "create" operator for the file system type of
the file system on which it's creating a file).

It also reveals that there's no code to explicitly turn off group write
permission.

Now, checking the S5R3 source reveals that its file system code *does*
use the umask - i.e., umasking isn't done at the system call level, it's
done at the file system level.  (I expect this to be fixed in S5R4,
given that S5R4 uses the same general sort of VFS mechanism as SunOS 4.x
and NFSSRC4.0.)  So it's conceivable that in an NFS implementation under
an S5R3-derived system, an "nfsd" with a umask of 022 could gratuitously
turn off group write permission.

It's also conceivable that some vendor might have screwed up and made
the file systems in a VFS-based system use the umask.