Xref: utzoo comp.protocols.nfs:1062 comp.unix.questions:23464
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!bloom-beacon!ora!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.protocols.nfs,comp.unix.questions
Subject: Why does NFS suppress group-write permission?
Message-ID: <417@minya.UUCP>
Date: 3 Jul 90 04:01:16 GMT
Followup-To: poster
Lines: 52

Well, maybe it doesn't, but that's what seems to be going on.

The gang I'm working with really needs to use groups to organize the
job, and we recently wasted a couple days tracking down the source
of a lot of annoying permission problems caused by files that should
have been writable by all of us, but weren't.  We first spent a lot
of time verifying that, no matter how we logged in (including via rsh
commands), our umasks were always 002, never 022.  But still, files
were scattered all over our directories with the group write bit off.
What the #*&$^*% was going on here?

After a bunch more experimenting, we finally found a whole lot of cases
in which directories and files were created with the group-write bit off,
although the umask was 002, and we spotted a pattern.  Whenever we tried
to create a file or subdirectory in a directory on a remote, NFS-mounted
filesystem, the group-write bit mysteriously ended up off.  When the
filesystem was local, it never happened.  Aha!

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.

Is this a bug or a feature?  Is it documented somewhere that I should
have found it?  Am I pointing an accusing finger at the wrong culprit?
Or was it perhaps done intentionally to punish turkeys like me that
have the gall to use groups?

For directories, the solution was easy.  I just wrote my own mkdir, 
which is a rather trivial little program, of course.  After it makes
a dir, it turns around and calls stat() on it, checks the permissions,
and if they are wrong, complains (if verbose mode is on) and chmods
them to what they should be.  Easy.  But it isn't so easy for other
types of files, since I can't easily get in a relink all programs in
the system library to a doctored version of open().

Anyone know the real story here?  Even better, is there a way to get
it to work right?  It puts a real crimp in our style to constantly
have to su and run "find . -exec chmod g+w {} \;&" to straighten out
the mess.

[BTW, I checked it out on several Suns, a couple of Ultrix systems,
an HP 9000 (Sys/V)  or two, and a few other random systems in the lab, 
and they all misbehaved the same way.]

-- 
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: [I've gotta get a new one of these some day.]