Red Hat Bugzilla – Bug 10468
linuxconf messes up after sendmail is removed
Last modified: 2008-05-01 11:37:55 EDT
Situation: sendmail RPM removed. Another mail server is installed which
provides a sendmail-compatible command line mail submitter.
/usr/sbin/sendmail, and others, are soft links that point to this sendmail
command line emulator. The other mail server's RPM also includes a
"provides" of "smtpdaemon".
When exiting linuxconf, linuxconf wants to do a bunch of things it really
shouldn't. linuxconf tells me that it wants to create /var/spool/mqueue,
because it's not there anymore.
Well, I wouldn't really mind that, it doesn't matter, except that linuxconf
wants to do something else that's a bit more disturbing. Apparently,
linuxconf reads the /usr/sbin/sendmail (or /usr/lib/sendmail) soft link,
and it wants to change the *underlying* executable's ownership and
permissions to what sendmail's permissions should be. That's what
linuxconf tells me that it wants to do, before it exits. The other mail
server's sendmail emulator is installed nowhere close to where sendmail
normally lives, and my mail server is not a monolithic root setuid beast,
and changing my mail server's command line injector to run setuid root is a
disaster that's waiting to happen.
There's no good reason for linuxconf to do this. sendmail is not
installed, there is no sendmail RPM, and there isn't anything calling
itself "sendmail" that's installed where sendmail normally lives.
This is fixed in Raw Hide; Linuxconf will no longer inspect or verify the
permissions on /usr/sbin/sendmail.