[comp.protocols.nfs] PCNFS, permissions, and UMASK

pickles@mpr.ca (Clive Pickles) (04/04/91)

This has probably been asked before (Ha!  What hasn't?! :-) but if it has,
I haven't seen anything about it.  Here is my problem:

I have created a file using PCNFS with permissions 770.  I would like people
in my group to be able to update this file.  However, when they do the
update, the permissions of the updated file are set to whatever the UMASK
is of the updater.  Most people have a UMASK of 027, so whenever they update
one of my files, the permissions are set to 750.  Because the owner of the
file is also changed, I now cannot edit that file.

This is different than Unix, which keeps the original file permissions and
owner until they are explicitly changed with chmod and chown.

I know that I could ask my users to do a "chmod" on the file after editing
it, but most people are running in a menu-shell environment, and do not
normally exit the "safe" environment of the menu.

I know WHY this happens (DOS copies the old file and renames the new one),
but I think that PC-NFS should be able to account for this.  We are running
PCNFS 3.0.1.  My questions is:  anybody know if this is changed for release
3.5?  Thanks to anyone who gives me an answer. 

-- 
===================================================================
= Clive Pickles - Systems Administrator MPR Teltech Ltd. (Ottawa) =
= Phone: (613) 787-4159 ------------------ E-mail: pickles@mpr.ca =
===================================================================

geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (04/05/91)

Quoth pickles@mpr.ca (Clive Pickles) (in <1991Apr3.195733.15063@ottsun1.uucp>):
#I have created a file using PCNFS with permissions 770.  I would like people
#in my group to be able to update this file.  However, when they do the
#update, the permissions of the updated file are set to whatever the UMASK
#is of the updater.  Most people have a UMASK of 027, so whenever they update
#one of my files, the permissions are set to 750.  Because the owner of the
#file is also changed, I now cannot edit that file.
#
#This is different than Unix, which keeps the original file permissions and
#owner until they are explicitly changed with chmod and chown.

Only because the Unix applications "know" about such things as
ownership. If a Unix editor used the create-temporary-copy, edit
copy, rename-original-to-bak, rename-temp-to-original model the file would
still wind up being owned by the person who edited it (unless the editor
was SUID-root and knew how to tweak this stuff).
#
#I know WHY this happens (DOS copies the old file and renames the new one),
#but I think that PC-NFS should be able to account for this.  We are running
#PCNFS 3.0.1.  My questions is:  anybody know if this is changed for release
#3.5?  Thanks to anyone who gives me an answer. 

No it isn't changed in 3.5. And how could PC-NFS (or LM/X, or PNW)
possibly "account for this". We just see a sequence of CreatFile, Rename,
Unlink, Read, Write..... calls. How are we supposed to grok that this
particular file is meant to be an edited version of this other file and
so should get a copy of the original owner & permissions. Come to think of
it, do you really want me to be able to create a file in your name?!

Solution: have everyone run with the correct UMASK.

Geoff

-- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)   --
------------------------------------------------------------------------------
--     Sun Microsystems PC Distributed Systems ...                          --
--            ... soon to be a part of SunTech (stay tuned for details)     --

rhoward@msd.gatech.edu (Robert L. Howard) (04/05/91)

geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:

>Solution: have everyone run with the correct UMASK.

Speaking of UMASK, has it been changed to work like the UNIX umask (i.e.,
umask 022 makes files permission 644 and diriectories permission 755)
rather than treating files and directories the same?

Robert

--
| Robert L. Howard             |    Georgia Tech Research Institute     |
| rhoward@msd.gatech.edu       |    MATD Laboratory                     |
| (404) 528-7165               |    Atlanta, Georgia  30332             |
-------------------------------------------------------------------------
|     "Reality is showing us that perhaps we should do with nuclear     |
|      power the same thing Keloggs is advocating for Corn Flakes -     |
|      Discover it again for the first time." -- John De Armond         |

geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (04/16/91)

Quoth rhoward@msd.gatech.edu (Robert L. Howard) (in <rhoward.670800628@romeo>):
#geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
#
#>Solution: have everyone run with the correct UMASK.
#
#Speaking of UMASK, has it been changed to work like the UNIX umask (i.e.,
#umask 022 makes files permission 644 and diriectories permission 755)
#rather than treating files and directories the same?

Yes, it was fixed. (Sorry for the delay in following up on this.)

-- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)   --
------------------------------------------------------------------------------
--     Sun Microsystems PC Distributed Systems ...                          --
--            ... soon to be a part of SunTech (stay tuned for details)     --