> Scott D Yelich <[EMAIL PROTECTED]> writes:
> > bingo. Lets say I had your setup. Fine, I type make and it uses "cc"
> > .. which, if it's sunpro, is better than gcc anyway,
> That's a matter of opinion.
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.
> > but *if* I wanted to compile using gcc? How would I do that? I'd have to
> > dig through the source until I found the "tricks" ...
>
> I read the install file and noted that it talked about modifying lots of
> files that started with conf-. I thought "huh, wonder what all there is."
> I did an ls conf-*, saw conf-cc and conf-ld, figured I'd better edit them,
> and did.
ucp* install mentions conf-home, but not others. sorry.
> >> Don't create multiple UID 0 accounts. You'll horribly regret it later.
> >> Been there, done that.
>
> > Why do people say this? What the hell does it matter?
>
> * 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.
> * Stuff gets confused. You already gave an example of that yourself.
Um. no and no. *I* am not confused. 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.
nothing gets confused with a second root entry.
> * You lose simple auditing. Rather than checking for root logins, you
> now have to check for logins on a bunch of random accounts.
Not true. Did I say the shell was interactive?
> * No one expects there to be multiple UID 0 accounts, since that's not
> the way a Unix system normally works. So they do things under the
> assumption there's only one UID 0 account and you can get security
> holes that way.
you are saying the same thing over and over without really providing
any concrete reasons.
> * Those extra accounts look like normal accounts but can't be dealt with
> via normal account management policies. Real example (yes, this
> actually happened): Someone was cleaning up after an employee who left
> the company and was using admintool to delete his accounts (yes, I
> know, first mistake...). Deleted the UID 0 account. Checked the box
> for "remove home directory" since it was the default. Whoops.
does admintool run the rm-user-home as the user or as root?
how would this differ from setting a normal user home to /?
so, lets argue a second root entry vs remote exploit/access
to your system via admintool.
Fine. This is the qmail mailing list. I'm trying to talk about qmail
-- but we're side tracked.
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. It's ok, for *me* because I have fought with
it and I canuse it, but for anyone else coming it, it's "not standard"
and I think it's in poor taste to do that to a client.
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).
Anyway, I'll now install tcpserver and see how long my mail is down.
I'll report back.
Scott
