Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!pasteur!agate!saturn!ucscc.UCSC.EDU!haynes
From: haynes@ucscc.UCSC.EDU (99700000)
Newsgroups: comp.bugs.4bsd
Subject: Re: bin owns stuff (was: Installing 4.3-Tahoe on a VAX)
Message-ID: <4828@saturn.ucsc.edu>
Date: 14 Sep 88 04:24:00 GMT
References: <26049@ucbvax.BERKELEY.EDU> <5416@zodiac.UUCP> <21791@sgi.SGI.COM> <8481@smoke.ARPA>
Sender: usenet@saturn.ucsc.edu
Reply-To: haynes@ucscc.UCSC.EDU (Jim Haynes)
Organization: California State Home for the Weird
Lines: 31

In article <8481@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <21791@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes:
>>Is there some risk with making root own everything?
>
>The basic idea is to avoid forcing the system administrator to act under
>UID 0 unless absolutely necessary.  Files owned by "bin" can be updated
>by "bin" rather than "root".

Well as I said when I started the whole thing (and I'm enjoying the
activity level of the subsequent discussion) it is really a philosophical
question rather than a right-or-wrong matter.  I prefer to have root
own everything so I only have to defend one UID against the world
instead of several.  But I can readily appreciate that other system
administrators might prefer to be able to work on the commands without
needing root privileges to do it.  Maybe the goal to shoot for is
having the owner of everything be a define in the top level Makefile
so the installer can do it either way without having to find and edit
all those individual Makefiles.

Now a second related issue is why have all those binaries mode 755 or
worse instead of 711, with 755 to be used only where needed?  Somebody
suggested the umask should be taken into account for installs; but
I'm not sure that is a good idea because you still need 755 for shell
scripts and a few binaries.  But making everything 755 allows a user
to make himself a complete binary-only copy of the system without
getting a license.  Not that I particularly worry about that; I'm
more concerned with trying to make it as hard as possible for the
crackers to find out what's wrong with the programs before I do.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes