Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: umask per directory?
Message-ID: <4122@ut-sally.UUCP>
Date: Tue, 4-Feb-86 22:31:02 EST
Article-I.D.: ut-sally.4122
Posted: Tue Feb  4 22:31:02 1986
Date-Received: Wed, 5-Feb-86 03:23:40 EST
References: <4034@ut-sally.UUCP> <4029@ut-sally.UUCP> <4060@ut-sally.UUCP>, <4083@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 52
Approved: jsq@sally.UUCP

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