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: <4107@ut-sally.UUCP>
Date: Mon, 3-Feb-86 16:15:35 EST
Article-I.D.: ut-sally.4107
Posted: Mon Feb  3 16:15:35 1986
Date-Received: Mon, 3-Feb-86 23:58:29 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: 32
Approved: jsq@sally.UUCP

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