jc@minya.UUCP (John Chambers) (07/03/90)
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.]guy@auspex.auspex.com (Guy Harris) (07/07/90)
>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.