Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!mace.cc.purdue.edu!dls
From: dls@mace.cc.purdue.edu (David L Stevens)
Newsgroups: comp.bugs.4bsd
Subject: Re: bin owns stuff (was: Installing 4.3-Tahoe on a VAX)
Message-ID: <647@mace.cc.purdue.edu>
Date: 16 Sep 88 17:58:18 GMT
References: <26049@ucbvax.BERKELEY.EDU> <5416@zodiac.UUCP> <21791@sgi.SGI.COM> <8481@smoke.ARPA> <21879@sgi.SGI.COM> <3224@geac.UUCP>
Reply-To: dls@mace.cc.purdue.edu.UUCP (David L Stevens)
Organization: PUCC UNIX Group
Lines: 52


	[2 articles for one low price!]

First:

Drew Sullivan <drew@lethe.uucp> writes:

	[talks about how someone other than root needs to own files...]

>..I can tell 6 months down the road what are local updated versions of
>files vs the stock (bin) distibuted files.

	That's what timestamps are for! If you want to know what's changed
in your home directory since some particular time, do you change all of the
ownerships?

> I have found that the need to go super user is slowing disappearing.

	Doesn't that pretty much mean you're essentially root all the time?

Second:

Also, Re: Chris Torek's remarks. I think you may have missed my point, Chris.
It doesn't matter if you set "bin" to uid 0 or if you call it "root" or "bob",
for that matter. The kernel uses the uid number so either the files will
be distributed owned as root, or they won't. Password file tricks won't save
that.
	I see where your method is convenient in that you can have all the
Makefiles have "bin" and then you can set "bin" to be root or not, as you
see it, but that's really sidestepping the issue. If you don't have sources,
which is generally true in the "real" world, it doesn't help at all, and
even if you do, you are required to either re-install everything or run
chown's, if you don't like the default uid *number* for system file ownership.
	What, then, have you gained? New installs will be the owner you've
chosen, magically, yes, but that isn't the major issue, unless you typically
change everything. Our local version of install(1) replicates the existing files
modes and ownership by default, so your solution, at least for us, does
absolutely nothing.
	Picking consistent uid (numbers!) for file ownership is what I'd
like to see; that may not be the issue you're addressing [I'm sure you'll
tell me if you've "already covered that" :-)], but that is what is relevant
to the majority of system administrators. We have discussed this locally
and have chosen root ownership and to remove the root->nobody mapping across
NFS links. We have been using "binary", a "bin" equivalent, but at best, it
gives us nothing and at worst, it gives us a false sense of security.
	Of course, if we see some new information that makes an id other
than root attractive, we'll change that. Unless I've missed something, your
suggestion still leaves installers with having to do chown's, except for
new installations, and a clever install(1) fixes that a little more cleanly
then password file dancing.
-- 
					+-DLS  (dls@mace.cc.purdue.edu)