Subject: Re: building a userland interface to a kernel structure
To: Objects In Mirror Are Closer Than They Appear <email@example.com>
From: Dustin Sallings <firstname.lastname@example.org>
Date: 01/12/1999 15:09:58
On Tue, 12 Jan 1999, Objects In Mirror Are Closer Than They Appear wrote:
Yeah, I guess it would make a lot more sense if I actually
explained what I was trying to do. I'm making the ``only root can bind to
ports less than 1024'' run a little more granular. For instance, on my
laptop, only root, or dustin can bind to port 444 or 80. I understand the
desire to be mostly sure of who's running the server you're connecting to,
but I don't understand the point of making all of these servers run as
root just so that they get the magic port. I don't want to give all of my
developers root access to the devlopment machines just so that they can
play with server X as it will be configured for production. I also don't
want to have to ``pull rank'' just to test out a piece of software I've
written, or maybe some third-party application that needs a low port, but
I don't necessarily trust with root access on my machine. Revoking root
isn't really an answer because my server does quite a bit of work before
it even determines it needs a low port to bind to, and may figure out
later that it should bind to another one. I brought this up on an OpenBSD
list before, but Theo suggested I just make the program run as root and
give up the uid after it does what it needs, which is a common approach.
I prefer to take the approach of making a user ``only root enough'' to do
the one little thing it needs that would otherwise require special privs.
I know root isn't going away as long as I stick with UNIX, but in
my world, root just grants privs, and the individual applications stay
within the restrictions of their own users, and I don't have to worry
about some random programming mistake giving someone access to my entire
system. This is what I'm trying to avoid.
Groups obviously don't apply here because this is currently a
toggle based on uid==0. Although they could apply if someone wanted to
get a lot more complicated than I am right now.
# You can "down with root" all you want, but as a UNIX user and administrator,
# I expect that there will be a deific user; if it goes away, I'll just
# create one who belongs to all access groups, myself.
# Not that ACLs are _bad_, mind you, IFF we can implement them intelligently
# (I don't think such a solution exists, actually).
# But "root" is a historical part of UNIX (NetBSD/Trademarks notwithstanding).
# I personally don't want to see "root" go away because that would seriously
# begin to impede what I do.
# On the other hand, if you're trying to say that certain users should be
# given certain accesses, well, that's what the group lists are for.
# I'm sure I'm missing something, and I'm really not trying to be acerbic
# about it, so please accept my apology in advance if I seem to be a
# smart-ass about it. I try to keep an open mind, but if there's no One
# True SuperUser on the system, having to decide who gets what access
# is a royal pain. I've had to administrate (sic) NT, and I don't like
# the granularity they have there -- it's possible to completely castrate
# the local administrator.
# Friends don't let friends use Windows NT.
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <email@example.com>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________