Dan,
When I run rpm to check a system it reports every file that has been changed
including alias.db (if I changed it). If ANY binarys have changed I do an
upgrade install of the suspect binarys, then I check the system again
(before fixing the configuration files for the new binarys) that tells me
what if any additiona files have been mucked with, those I have to
individually check and I do. Qmail currently I have to destroy both the
binarys and the sources, download new ones and install, compile, test and
run from scratch.
Here is the difference with a Red Hat machine with 8 Gig of HD and with
sendmail installed a check and restore takes under 20 minutes, usually under
15. The same machine with qmail installed takes the same 15- 20 minutes to
validate the machine and then I have to delete qmail and start freash
generally adding an additional hours time at least.
If you would get over it and have qmail read out of a configuration file it
would save me an hour per machine per installation, and an hour anytime a
machine is broken into. Red Hat would make a binary and a source rpm and I
could eliminate first installing sendmail and deleting it only to install
qmail.
You are being stubborn and obtuse, get over yourself. I use qmail, I
recomend that newbies use the installed sendmail since it is easier to leave
it be then to install qmail the hard way. I would prefer to tell them to use
qmail but YOUR choices force me to tell them to use a less secure product. I
finally patched qmail to read from a configuration file I am not about to
tell a novice to c programming to patch qmail and then compile it, not today
not ever.
If you don't want to have qmail use the same method almost everyother
program uses to et uid/gid info, well ok, then use a configuration file,
don't cause the binarys to need to be edited, that is plain stupid. You
insistance on this causes me to have to deinstall qmail anytime I suffer a
breakin, even if more then likely the cracker did not touch the qmail
binarys, that gets real old real fast.
David Mandala
Quoting D. J. Bernstein ([EMAIL PROTECTED]):
> Russell Nelson writes:
> > Users commonly recompile /etc/alises.db.
>
> So what? A trojaned /etc/aliases.db has an excellent chance of sticking
> around long enough for an intruder to break in again.
>
> If you have a method of guaranteeing a clean /etc/aliases.db after a
> breakin, why can't you use the same method for the qmail files?
>
> Your suggestion, apparently, is to reinstall /etc/aliases.db. Why don't
> you think that exactly the same solution works for a var-qmail RPM?
>
> > If Redhat requires it's binaries to be unmodified for security reasons,
>
> It doesn't. /etc/aliases.db is a binary, modified on most systems.
> What's wrong with handling the qmail files the same way?
>
> ---Dan
