(If I sound upset, btw, I'm not.  So don't read that into tone; it's not
meant.)

Scott D Yelich <[EMAIL PROTECTED]> writes:

> hahah.... fine.  I'll leave it at the code that I used to benchmark sun
> ultra code from sunpro-cc and gcc -- the sunpro-cc was 20% faster.
> That's how I base my opinion.  I'm sure there are other factors.

Yes, like a compiler that works the same and takes the same flags across
the eight different platforms I have to support.

>>  * You're allowing multiple access paths to what should be the most
>>    secure account on your system.  You now have *multiple* potentially
>>    compromised passwords rather than just one.  You have to check and
>>    maintain all of them.  Not good.

> baloney.  If the passwords are the same, then you still only have one
> password.

Whether you set the password to the same thing on all the accounts or not,
there are now multiple privileged password entries.  They *can* be
different (or made different by an attacker).  Keeping more than one thing
secure is harder than keeping one thing secure.

Most of the installations I've seen with multiple UID 0 accounts set the
passwords to different things.  You're being more intelligent about it
than most; that's good.

>>  * Stuff gets confused.  You already gave an example of that yourself.

> Um. no and no.

You said that Solaris has a boot script that does a text check for root
and gets confused if there's a UID 0 account in /etc/passwd before root.

> I am fighting and arguing with people on this list over what I feel
> would be contributions to the overall documentation style of qmail
> components.

No, you're fighting and arguing with people on this list about all sorts
of random other topics.  I've yet to see anyone say that a line in INSTALL
mentioning where to configure the compilers would be a bad thing.

> you are saying the same thing over and over without really providing any
> concrete reasons.

I am giving you a concrete reason.  "People get confused."  You have not
yet encountered people who are confused by this.  I'm glad for that.  I
have.  There are a lot of them.  I've done this before I've seen them get
confused.  I've seen the problems that result.  I think it's a bad idea,
and therefore recommend that other people don't do it.  I'm not going to
break into your machine and remove your extra UID 0 accounts; if you don't
agree with me, that's your lookout.  It's not going to break your system
to have multiple UID 0 accounts; it's quite possible to maintain a system
in that fashion.

> does admintool run the rm-user-home as the user or as root?  how would
> this differ from setting a normal user home to /?

It doesn't.  Don't do that either.  :)

> so, lets argue a second root entry vs remote exploit/access to your
> system via admintool.

admintool isn't an exploit.  admintool is something that people who don't
really understand a Solaris machine use to do things on it.  If you
thoroughly understand your machine, you can do anything you want to it and
probably make it work with enough persistance.  If you want people who are
used to normal Unix systems or people who don't really know what they're
doing to be able to work with your box, in my experience UID 0 accounts
other than root are a bad idea.

> I consult for an ISP that uses sendmail -- sorry, there's no way in hell
> that I'm going to instll qmail due to how non-standard it is and how
> poor the documentation is.

You don't need to defend your choice of an MTA.  I run both qmail and
sendmail and am considering Postfix for other things.  Lots of us are like
that.  It's not a binary choice.  In fact, casting suggestions in terms of
"I can't install qmail because X is broken" tends to be needlessly
inflammatory.

> So, this client owns their own isp.  They have root access.  They often
> type "passwd" without an account to change the password for one of their
> account -- yet they zap the root password.  Ignore my solution -- how
> would you prevent this provided that the isp owner will not stop using
> the command and you don't want to write a wrapper for them around the
> root command (since it's not a single person who does this).

So you have someone with root access who regularly types incorrect
commands as root and is unwilling to learn how to do it right and you
can't take root away from them.

You're right.  Ignore my suggestions about UID 0 accounts; they'll be the
least of your problems.

-- 
Russ Allbery ([EMAIL PROTECTED])         <URL:http://www.eyrie.org/~eagle/>

Reply via email to