Bug 186917 - /bin/mail command fails to send mail - RunAsUser issue
/bin/mail command fails to send mail - RunAsUser issue
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sendmail (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-03-27 09:18 EST by Bevis King
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-18 08:16:09 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 Bevis King 2006-03-27 09:18:27 EST
Description of problem:
The /bin/mail command has stopped being able to send mail with an error message
related to RunAsUser during the last week.

Version-Release number of selected component (if applicable):

How reproducible:
Every time, on a significant number of RHEL4 Nanant Update 2 machines of both
i686 and x86_64 architectures.

Steps to Reproduce:
1.   mail root < /etc/motd

Actual results:
i686 box:
% mail root </etc/motd 
% WARNING: RunAsUser for MSP ignored, check group ids (egid=25, want=51)
can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
required=25): Permission denied
x86_64 box:
% mail root < /etc/motd
% WARNING: RunAsUser for MSP ignored, check group ids (egid=25, want=51)
can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
required=25): Permission denied

Expected results:
contents of /etc/motd is emailed to root.

Additional info:
Comment 1 Bevis King 2006-03-27 10:16:03 EST
Looks like it was the patch for sendmail security bug (RHSA-2006:0264-8  
Critical: sendmail security update) that caused this.  One system did not
download this update and /bin/mail on this host is still functioning normally.
Comment 2 Bevis King 2006-03-27 10:28:32 EST
This problem also affects FC4 (both i686 and x86_64) and FC5t3 boxes.
Comment 3 Radek Bíba 2006-03-27 15:00:27 EST
I was invited to this bug report but I can't reproduce it anywhere on my testing
machines with standard sendmail and mailx configuration. CC'ing sendmail
maintainer, he might know if this is a regression or some unhealthy setting.
Comment 4 Radek Bíba 2006-03-28 03:38:53 EST
Hmm, I was able to produce very similar error by removing setgid bit from
/usr/sbin/sendmail.sendmail and adding access to /var/spool/clientmqueue for
others, which definitely isn't a sane configuration. Then, if and only if I run
the command as non-root I get:

$ mail root < /etc/motd
$ WARNING: RunAsUser for MSP ignored, check group ids (egid=100, want=51)
can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=100,
required=51): Permission denied

Though the difference between this and your output is that the numbers in the
second parentheses are RunAsGid = GID of the user running mail(1) and required =
GID of smmsp, while in your case RunAsGid = root's GID and required = 25,
apparently GID of user running mail(1).

Bevis, could you check permissions and ownership of /usr/sbin/sendmail.sendmail
and /var/spool/clientmqueue anyway, please?
Comment 5 Bevis King 2006-03-28 05:19:24 EST
A colleague writes:
Finally got a chance for a quick look at this and I think it is still a
perms problem caused by the difference in the smmsp NIS entry in passwd
and group and the local /etc/passwd,group files.

Here is some stuff from one of the failing servers. Note this server is running
with uid 51 and group 51 which is local passwd ids. Ls lists the sendmail and the
clientmqueue as smmsp but using ls -ln - we can see that the
clientmqueue is really 25 group.

- So the issue basically seems to be that this update has caused our mail system
GIDs from the NIS no longer work wnen they did previously.  This has killed
almost all email service on most of our machines, so it's really bad news
Comment 6 Bevis King 2006-03-28 05:29:10 EST
-rwxr-sr-x  1 root smmsp 733912 Mar 20 11:57 /usr/sbin/sendmail.sendmail
-rwxr-sr-x  1 0 25 733912 Mar 20 11:57 /usr/sbin/sendmail.sendmail

drwxrwx---  2 smmsp smmsp 4096 Mar 20 11:57 /var/spool/clientmqueue
drwxrwx---  2 51 25 4096 Mar 20 11:57 /var/spool/clientmqueue
Comment 7 Bevis King 2006-03-28 05:33:50 EST
More comments from our local discussion which are pertinent:
OK, hold on the remove the NIS smmsp as that is the normal default for
sendmail and is the account used by solaris sendmail - why is
the local passwd/group on RHEL 51?

I've temporarily fixed the server we were testing with 

chgrp 51 /var/spool/clientmqueue
chmod g+s /usr/lib/sendmail

as Simon had done on SuSE. This sets it correctly. The question is which is
easier to change, RHEL local passwd group from 51 to 25 or solaris/CSW
from 25 to 51 OR move solaris ids to local files and remove smmsp from

I would imagine other people with both Solaris and RHEL4 boxes running from the
same NIS could be in trouble with this.
Comment 8 Radek Bíba 2006-03-28 05:50:42 EST
Reassigning to sendmail, then.

As for eventual changes in UIDs/GIDs in RHEL, GID 25 is already reserved for
bind (see /usr/share/doc/setup-2.5.37/uidgid).
Comment 9 Thomas Woerner 2006-07-18 08:16:09 EDT
I am sorry, but I can not change the uid or gid for smmsp in RHEL.

Closing as "not a bug".

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