[mod.std.unix] umask per directory?

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/31/86)

Date: Fri, 31 Jan 86 13:19:46 cst
>From: ihnp4!utzoo!lsuc!msb (Mark Brader)
Organization: Law Society of Upper Canada, Toronto

> From: mcnc!duke!rrt@seismo.UUCP (Russ Tuck)
> Subject: Re: TZ and TERM per process
(May I remind the moderator to watch out for inappropriate Subjects?)
[ You're right:  I missed that one.  -mod ]

> I heartily agree that umask should be per-directory rather than per-process.
> This is more natural and useful, allowing related files to be given the same
> protection automatically as they are created in a directory.  

And I heartily DISAGREE.  My umask is 022, and when I create a file
whose mode is not 644 or 755, it is a rare and earthshaking event.
Seems to me that if I was a secretive umask 077 type, or a permissive
umask 0 type, I'd feel exactly the same way.  Directories with booby
traps are the mark of VMS, not UNIX.

[ The moderator reminds the posters that attacks on ideas as being
appropriate to a given operating system don't add much to the discussion.
Furthermore, if you set the umask on your home directory to 022,
and that were inherited through your directory subtree, you would
get the same effect for your files as with a per-process umask.

I'd be really interested in any comments from John Mashey as
to what arguments arose concerning this idea when the per-process
umask was decided upon.  -mod ]

		 { decvax | ihnp4 | watmath | ... } !utzoo!lsuc!msb
		    also via { hplabs | amd | ... } !pesnta!lsuc!msb
Mark Brader		and		   uw-beaver!utcsri!lsuc!msb

Volume-Number: Volume 5, Number 25

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/04/86)

Date: 2 Feb 86 21:02:09 EST (Sun)
>From: floyd!opus!ka@SEISMO.CSS.GOV ()
Organization: Bell Labs, Holmdel, NJ

I agree with Mark Brader.  In response to the moderator's suggestion
that "if you set the umask on your home directory to 022, and that were
inherited through your directory subtree, you would get the same effect
for your files as with a per-process umask," I would point out that
this doesn't work for files in /tmp.

[ Good point.  Assume the old per-process umask still exists as a default,
though.  (I've been assuming that but haven't mentioned it.)  If /tmp
has no directory umask, things work.  Most of the other objections
are also accounted for.  -mod ]

My major objection, though, is that the proposal would break existing
programs.  For example, tar and cpio would have to be modified to
handle the per-directory umask.  This would mean new tar and cpio tape
formats, which would probably be unreadable by existing versions of tar
and cpio.  I wrote a version of rcp a couple of months ago which would
have to be changed.  Programs as unlikely as ed and passwd would
require modification.

In my view, the benefits of going to per-directory umasks are
outweighed by the disadvantages.  I might be convinced otherwise with
additional argument.  But changes which are not backwards compatible
must be justified by *major* benefits.
				Kenneth Almquist
				ihnp4!houxm!hropus!ka	(official name)
				ihnp4!opus!ka		(shorter path)

Volume-Number: Volume 5, Number 32

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/05/86)

Date: Sun, 2 Feb 86 23:48:32 pst
>From: ihnp4!decwrl!mips!mash (John Mashey)

1] I don't believe the idea of associating uname values to directories
was ever discussed, as far as I can remember.  The whole thing really
came about because PWB/USG believed that security had to be tightened,
and Research and some others wanted to continue to run conveniennt loose
systems.  It was believed that setting a default per systems was fine,
but needed to be overridden as needed, so it it was put in to be inherited
in the same way as most other thigns, i.e., by process tree inheritance.

2] I doubt whether the idea would have been considered seriously if
it had been brought up, at least if umask were the only reason for
adding the mechanism.  Why?
a) Remember that UNIX was designed by people who'd been working on
MULTICS, whose directories include considerable more protection
information.
b) However, UNIX directories are ONLY names.  There is no
system-implied state (except for the current directory itself)
implied by the current directory.  Nothing else is inherited or
modified by one's position in the file system.
c) I can't remember the reference, but I'd swear that one of the
early papers said that b) was on-purpose.
d) This doesn't mean the idea is necesarily bad, merely that I doubt
anybody would have believed that it fit with UNIX.

3] [PHILOSOPHICAL HARANGUE]: kernel mechanisms should be added only
when really justified by serious need.  In particular, one should
try to make new mechanisms be general enough to cover numerous
special cases, not add special cases one by one.  In this case,
good questions to ask are:
	Is there per-process state information [either in the u-area
	or returned by doing a chdir(2)] that should be changed
	automatically when doing a chdir?  If so, can one store this
	in a file in the directory?  Are pieces of state added, deleted,
	merged, inherited, etc? 
If one can come up with a few examples, then perhaps the general
mechanism could be designed.  One could easily experiment with
this: for example, the chdir function call might be augmented
in any of many ways. It would be much more enlightening to hear
a proposal for a general mechanism, backed up by multiple examples &
illustrations of existing attempts within the systems to achieve the
effects.  [END PHILOSOPHICAL HARANGUE]

[ Now *that* was an article!  But I don't understand what chdir
has to do with it:  the idea is to create a new file according to
the umask of its parent directory, not of the current directory.
I.e., "cat this > there/that" should create "that" in the same
modes according to the umask of "there" regardless of what "." is.
-mod ]

Volume-Number: Volume 5, Number 37

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/06/86)

Date: Tue, 4 Feb 86 14:05:09 est
>From: "Charles J. Antonelli" <cja%eecs.umich.csnet@CSNET-RELAY.ARPA>
Summary: Use an appropriate alias for `cd' [ Nope. -mod ]
Organization: University of Michigan EECS Dept.

I obtained the following idea from a colleague.  It can be used with csh
to achieve the desired effect.  Define the following alias:

alias cd 'if (-o .exit ) source .exit; chdir \!*; if (-o .enter ) source .enter'

Then create .enter and .exit files within the directories whose umasks
are to be controlled; the files contain the appropriate umask commands along
with anything else you wish to do whenever a directory is entered or exited.
In my case the new umask is echoed for verification.

The .exit file is useful mainly in those cases where only a small subset
of the directories have .enter files; if every directory has one then
.exit is not strictly necessary.

The alias checks for ownership to prevent possible corruption.

Charles J. Antonelli		Phone:  (313) 763-1563
The University of Michigan	Csnet:  cja@eecs.UMICH
1508 East Engineering		Usenet: cja@umich.UUCP
Ann Arbor, MI   48109			ihnp4!umich!cja

[ This is one of several such shell initialization schemes I've
received (and the only one I'm going to post).  They all miss the
point:  a new file should be created according to the modes of its
*parent* directory, not the creating process's *current* directory.
That is, "cat this > there/that" should create "that" with the same
modes regardless of where "." is.  (If "there" has the directory umask
feature enabled.)  -mod ]

Volume-Number: Volume 5, Number 38

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/06/86)

Date: Wed, 5 Feb 86 17:43:47 est
>From: seismo!harvard!think!mit-eddie!jbs (Jeff Siegal)

No one is suggesting "fixing" umask, only adding new capabilities
for those who will choose to use it.  I personally think that
allowing people to choose the way they want to do things, rather
than trying to second-guess what will be best.

Volume-Number: Volume 5, Number 40

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/07/86)

Date: Fri, 7 Feb 86 01:12:07 pst
>From: pyramid!decwrl!mips!mash (John Mashey)

Re: having followed this discussion somewhat randomly, I thought that
was one the ways that people were casting this, and so cast the example
that way.  Perhaps a better way to state the general case is:
	a) one needs to specify the state vector associated with each
	object in the system.
	b) One must specify how operations depend on the state of the objects.
	c) Any time one adds a new item to an existing state vector,
	one should carefully check to see that it is needed, and is as general
	as makes sense, not just a special case.
	d) ANy time one adds an enitre new state vector, or a completely
	new kind of interaction with operations, like c), but more so.

Certainly, I don't feel very strongly about any of this, EXCEPT that
this feels to me like a wart of the following nature:
	a) It is a special case of potential value.
	b) It is a special case of some general case that has not yet been
	expressed.
	c) It is not of such critical nature that it should be implemented
	without better understanding the general case.
	d) If somebody really wants to, they can get almost any of
	the proposed effects by using 1) tweeked creat(2) Interface routine,

	2) environ variable checked by the new creat()
	3) a dot-file with umask value left in each directory.
The questions is: does anybody who has the source to do this have enough
interest to try this out?

Volume-Number: Volume 5, Number 42