Description of problem: When sendmail is invoked via the command line, it cannot access the database map files, which causes certain operations (such as genericstable rewrites) to fail. The makemap(8) program creates database map files which are mode 0640. If the TrustedUser option is set in the sendmail.cf file, the makemap(8) program additionally sets the file ownership of the database map files it creates: So, database files will either look like this: 4 -rw-r--r-- 1 root root 1429 May 7 19:00 genericstable 12 -rw-r----- 1 root root 12288 May 7 19:00 genericstable.db Or like this: 4 -rw-r--r-- 1 root root 1429 May 7 19:00 genericstable 12 -rw-r----- 1 smmsp root 12288 May 7 19:00 genericstable.db Regardless, because the sendmail program is only set-group-ID (not set-user-ID), when sendmail is invoked via the command line, it cannot access the database map files. There are multiple ways to work around this problem: 1. Make the sendmail program set-user-ID to smmsp. 2. Make /usr/sbin/makemap set-group-ID to the same group as sendmail. 3. Have /etc/mail/Makefile manually chgrp(1) each db map file to smmsp. There are problem other methods that would work as well, but options #1 or #2 would seem to be the most likely candidates. Both options, however, have non-trivial security ramifications. This isn't so much a bug as it is a misfeature: there doesn't appear to be any evidence that the sendmail authors realized that 1) sendmail will need access to the database map files if it is invoked from the command line, and 2) having the sendmail program set-group-ID is not sufficient to grant access to the database map files. As such, I think the sendmail authors are going to have to clarify how to proceed. In fact, I was considering submitting this bug directly to sendmail-bugs (because it's not a Red Hat problem per se). However, I wanted to make Red Hat aware of the problem as well. (And I also wanted to have a handy URL to throw at other people who run into this problem. ;) Thus, if you want to pass this upstream and close as DEFERRED, IMHO, that would be perfectly reasonable. Version-Release number of selected component (if applicable): sendmail-8.12.8-5.90
On a related note on redhat 8 I've a problem with the sgid permissions sendmail runs with from the command line which means local users cannot send mail! Here are other reports of the problem: http://216.239.53.104/search? q=cache:MJSnKtuJYdAJ:https://www.redhat.com/archives/redhat-list/2003- July/msg03122.html+Program+mode+requires+special+privileges+sendmail+redhat&hl=e n&ie=UTF-8 It seems this problem affects various distributions. Now I tried changing group ownership of /var/spool/mqueue to smmsp and then got the errors about unsafe ownership of the DB files.
Hello James Ralston, I don't think sendmail needs access to the map files if invoked from the user. I have uploaded the newest sendmail rpm to http://people.redhat.com/laroche/ . If you still see problems with that version, please let me know. This can be used to debug the access checkings that sendmail does for the map files and to make sure it is not using those: echo test | /usr/sbin/sendmail user@localhost -d44.4 This has map files only readable by root and only /usr/sbin/sendmail daemon running as root will need those. greetings and thanks for your report, Florian La Roche
Hi Florian, Sendmail *does* need access to the map files if invoked from the user. To prove it, put this line in your /etc/mail/genericstable file: laroche laroche+rewrite Make sure your sendmail.mc contains these lines: define(`confTRUSTED_USER',`smmsp')dnl FEATURE(`allmasquerade')dnl FEATURE(`genericstable', `hash -o /etc/mail/genericstable')dnl FEATURE(`masquerade_envelope')dnl Make sure your submit.mc contains these lines: FEATURE(`genericstable', `hash -o /etc/mail/genericstable')dnl FEATURE(`masquerade_envelope')dnl The finally, cd to /etc/mail and run: $ make clean $ make Your genericstable.db should now be mode 0640, user smmsp, group root. Now test the rewriting: $ echo foo | mail -s test -v laroche The genericstable rewriting won't occur. Now do this: $ chown root:smmsp genericstable.db $ echo foo | mail -s test -v laroche The rewriting *will* occur now. Conclusion: when sendmail is invoked from the command-line, it needs to be able to read the map files. This is still true with http://people.redhat.com/laroche/sendmail-8.12.9-12.src.rpm (I just tested with it).
You have put the reqriting in both and only having it in sendmail.mc should be enough with having the correct entry in the G class etc. The above example looks like a wrong approach. Can you name a reason why this map "must be" in submit.mc? greetings, Florian La Roche
Because up until this point, I had been unable to get FEATURE(`genericstable') in sendmail.mc to trigger the rewriting. The problem is that class {G} does not automatically contain the contents of class {w}, requiring one to use GENERICS_DOMAIN(`my.domain') in sendmail.mc. However, without a specific MASQUERADE_AS statement in submit.mc, submit.mc will rewrite a bare <user> to <user>, which won't match the GENERICS_DOMAIN statement in sendmail.mc. Stuffing the FQDN into class {G} is one way to resolve the problem. However, this is a pain, because it makes the resulting sendmail.mc specific to each machine, instead of being specific to a domain. (Populating class {G} from a file is slightly better, but still a pain.) Duplicating all of the masquerade-related statements from sendmail.mc to sendmail.cf will also solve the problem, at the expense of having to maintain individual submit.mc files for each domain one administers. So, I retract what I said in comment #3: it *is* possible to have FEATURE(`genericstable') in sendmail.mc only, and still have everything work. Nonetheless, I still think it's completely stupid that sendmail MSP can't access the map files. Having the map files be (mode 0640, user smmsp, group root) serves no purpose: /usr/sbin/sendmail is set*gid* to smmsp. Therefore, the *only* user who can access the map files is root, and root has access regardless of what the mode/user/group settings are. The map files should be (mode 0640, user root, group smmsp). It's the only mode/user/group combination that makes sense, and doing so would allow the sendmail MSP to access the map files.
sendmail upstream wants to have map files per default only readable by root and this is for sure the most secure setting. This is already relaxed by having the plain text files 0644 for the default configuration. Maybe this should really be more open and if s.o. insists on having untrusted users on the mail server, this could become a local sysadmin task to make the config files again unreadable for non-root. The other issue is: If you do a "chmod 0644 /etc/mail/*.db", sendmail will keep the perms of those files, even if the .db files are updated, so this might be also a good enough solution for a server setup. will re-think this item, Florian La Roche
Actually, as I discovered the hard way, if you add the target of MASQUERADE_AS to class {G} on a server that relays, sendmail will *throw away* the "+detail" on messages relayed through the server. The more I ponder this issue, the more I conclude that the MSP should be able to access the map files; in particular, the genericstable map. The main point of the genericstable is to rewrite UNQUALIFIED addresses. The MSP is what receives the unqualified addresses! Having the MSA punt genericstable rewrites to the MTA enormously complicates the picture. If upstream wants the MSP to be unable to access the map files (despite the fact that the source files from what the map files are built are accessible!), then that is idiocy. I'm going to go to comp.mail.sendmail and bit^H^H^H^H post constructive criticism now.
Any new information on how sendmail.org is handling this issue? Thanks, Florian La Roche
Closed due to user inactivity.