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 dir Message-ID: <4118@ut-sally.UUCP> Date: Tue, 4-Feb-86 16:16:28 EST Article-I.D.: ut-sally.4118 Posted: Tue Feb 4 16:16:28 1986 Date-Received: Wed, 5-Feb-86 03:30:21 EST Organization: IEEE/P1003 Portable Operating System Environment Committee Lines: 37 Approved: jsq@sally.UUCP Date: Tue, 4 Feb 86 11:04:50 EST >From: Dan Franklin I have always felt that the UNIX umask "solution" to the problem of protection was inadequate. If I had per-directory protections, then my personal hierarchy would be writable only by me (644), except for my mail files which would be even more private (600). The source hierarchy I share with others on my project would be read-write by the group (664). Since all we have is umask, I can't do this. I must set umask to 002 so that when I work on the group source hierarchy, others can modify my modifications. I put up with the lessened security in other areas because most programs implement various ad-hoc solutions--the mail system creates all its files 600, etc. It's not perfect; when I use a filter on a message file in one of my MH folders, the output file is created group-read-write. But it mostly works. The cd alias is a clever suggestion, but like umask, it only mostly works. Your shell, and the shells of all the other users you ever expect to create files in those directories, must have aliases (thus leaving out users of the BSD Bourne shell and the System V.1 shell) and it doesn't work with commands like "find," which can recurse over a hierarchy and create files (via -exec) without ever forking a shell of any kind. Some daemons don't exec shells, or only exec the Bourne shell (/etc/rc, for instance). However, just because umask is inadequate doesn't mean this committee should try to fix the problem. This inadequacy is not widely enough recognized to justify creating a brand-new scheme in a standards document without testing it. Also, the standard would (I think) have to retain umask in its current form; and having two ways to do the same thing is always unfortunate. Other submitters have also raised good points about compatibility (tar and cpio). So much as I like the idea, I think it has to be left for innovators to try adding, not for a standard. [ No one has proposed changing umask in a standards document. -mod ] Dan Volume-Number: Volume 5, Number 35