This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 90423 - command-line sendmail cannot access db map files
command-line sendmail cannot access db map files
Product: Red Hat Linux
Classification: Retired
Component: sendmail (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-05-07 19:49 EDT by James Ralston
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-14 07:12:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Ralston 2003-05-07 19:49:13 EDT
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 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

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 (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):

Comment 1 Need Real Name 2003-08-13 06:02:09 EDT
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:

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.
Comment 2 Florian La Roche 2003-09-01 10:17:42 EDT
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 .
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
Comment 3 James Ralston 2003-09-03 18:33:57 EDT
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 contains these lines:

FEATURE(`genericstable', `hash -o /etc/mail/genericstable')dnl

Make sure your contains these lines:

FEATURE(`genericstable', `hash -o /etc/mail/genericstable')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 (I just tested with it).
Comment 4 Florian La Roche 2003-09-04 08:42:59 EDT
You have put the reqriting in both and only having it in 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


Florian La Roche
Comment 5 James Ralston 2003-09-04 15:14:22 EDT
Because up until this point, I had been unable to get FEATURE(`genericstable')
in 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 
However, without a specific MASQUERADE_AS statement in, will
rewrite a bare <user> to <user@hostname.domain>, which won't match the
GENERICS_DOMAIN statement in

Stuffing the FQDN into class {G} is one way to resolve the problem.  However,
this is a pain, because it makes the resulting 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 to will also solve the problem, at the expense of having to maintain
individual files for each domain one administers.

So, I retract what I said in comment #3: it *is* possible to have
FEATURE(`genericstable') in 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.
Comment 6 Florian La Roche 2003-10-14 08:47:56 EDT
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
Comment 7 James Ralston 2003-12-08 06:22:49 EST
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.
Comment 8 Florian La Roche 2004-01-13 04:56:38 EST
Any new information on how is handling this issue?


Florian La Roche
Comment 9 Thomas Woerner 2004-06-14 07:12:33 EDT
Closed due to user inactivity.

Note You need to log in before you can comment on or make changes to this bug.