Sendmail - RunAsUser=sendmail:mail/What files to i have to change
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Sendmail - RunAsUser=sendmail:mail/What files to i have to change
My security book says its a great idea to use the RunAsUser option in sendmail. It says you also have to change ownership on many files including /var/spool/mqueue, alias lists, and :include: files. UMMMMM.......Does someone know exactly what files need to be changed. Im afraid Ill mess something up once again. I have no idea what alias lists and :include: files are.
accessable/executable by the RunAsUser (IIRC):
everything you get when executing "whereis sendmail" + /etc/mail + /var/spool/mqueue (+ /etc/aliases.db + /etc/aliases.db, IIRC) + change shell to smrsh, the restricted sendmail shell.
Why am i getting this error?
The permisssions look ok
My sendmail.cf has:
O RunAsUser=sendmail:mail
I created it via:
useradd sendmail -g mail
???
-rw-r--r-- 1 sendmail mail 424 Jan 8 18:37 access
-rw-r--r-- 1 sendmail mail 12288 Jan 10 18:54 access.db
-rw-r--r-- 1 sendmail mail 0 Mar 3 2001 domaintable
-rw-r--r-- 1 sendmail mail 12288 Jan 10 18:54 domaintable.db
-rw-r--r-- 1 sendmail mail 0 Jan 7 06:54 helpfile
-rw-r--r-- 1 sendmail mail 79 Jan 7 07:09 local-host-names
-rw-r--r-- 1 sendmail mail 0 Mar 3 2001 mailertable
-rw-r--r-- 1 sendmail mail 12288 Jan 10 18:54 mailertable.db
-rw-r--r-- 1 sendmail mail 611 Mar 3 2001 Makefile
-rw-r--r-- 1 sendmail mail 15 Jan 7 07:07 relay-domains
-rw-r--r-- 1 sendmail mail 2292 Jan 7 06:55 sendmail.mc
-rw-r--r-- 1 sendmail mail 127 Mar 3 2001 trusted-users
-rw-r--r-- 1 sendmail mail 0 Mar 3 2001 virtusertable
-rw-r--r-- 1 sendmail mail 12288 Jan 10 18:54 virtusertable.db
/etc/rc.d/init.d/sendmail start
Starting sendmail: makemap: error opening type hash map /etc/mail/virtusertable: Permission denied
makemap: error opening type hash map /etc/mail/access: Permission denied
makemap: error opening type hash map /etc/mail/domaintable: Permission denied
makemap: error opening type hash map /etc/mail/mailertable: Permission denied
[ OK ]
Sendmail binary needs to bind to a socket < 1024, so it needs an UID that is allowed these privileges. Thats why the doc's handling say it uses the RunAsUser UID after binding to the socket, your sendmail binary is setuid sendmail, and not setuid root, and thats why the rest of the files need to be readable by the RunAsUser UID.
Btw, mailertable should exist somewhere, because it's needed by the makemap utility:
"find / -name mailertable -print" should show it.
Ok. Ill just give a rundown of what I did to make use of the RunAsUser "feature". I already got the user "mail", I'm using Linuxconf to handle rendering sendmail.cf, and I've got my extra options in /etc/mail/mailconf/stdoptions.cf (the horror, the horror). Hope this checklist helps and I didnt forget anything essential.
1. Add lines to stdoptions.cf so they get processed (else use /etc/mail/sendmail.mc and use the proper m4 calls):
# Suid user
O RunAsUser=mail
# Cant write /var/run
O PidFile=/tmp/sendmail.pid
# Who owns files
O TrustedUser=mail
# Uid running mailer
# see CERT about sendmail buffer overflows.
O DefaultUser=mailnull
2. "mailconf --generatecf" or render with "m4 /etc/mail/sendmail.mc > /etc/sendmail.cf"
*note mailconf also does the "makemap -o hash etc etc" stuff.
3. "chown -R mail.mail /etc/mail; chown mail.mail /etc/aliase* /etc/sendmail* /var/spool/{mqueue,mail} /var/lib/mailertab*"
4. restart sendmail and check its logs.
Thanks unSpawn. I did exactly what you posted and it worked. I was missing some of the sendmail.cf stuff.
One last question regarding this. Im using qpopper for pop3. Now that sendmail runs as user sendmail, qpopper has a problem. I can no longer send or receive mail via pop3. Im not sure if this is a config change on the sendmail side or the qpopper side. I have went through both configs and I cant figure this out. I have also searched and come up empty handed.
Maybe you know or can direct me to somewhere that i can search to figure this out.
Thanks as always.
Things that come simple to others is a true mofo for me.
First guess would be to check the qpopper log for errors, if none show up check the sendmail log, if none show up, start qpopper with the -d option and see if it adds debugging info to its log, (same for sendmail if its sendmail related ofcuz). If this doesn't do a thing check the permissions on where qpopper is sposed to write its dotlocks (mail spool), it expects "root.mail", where you just made it "sendmail.sendmail", so maybe we should make it "sendmail.mail", or "root.sendmail" and "chmod 0770 /var/mail" so its writable for owner and group. If this doesn't do a thing check the Qpopper manual/faq/website...
HTH somehow, plz report back any clues, ok, I'm no guru :-]
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.