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): mailx-8.1.1-33 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:
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.
This problem also affects FC4 (both i686 and x86_64) and FC5t3 boxes.
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.
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?
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 operationally.
Results: -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 and: drwxrwx--- 2 smmsp smmsp 4096 Mar 20 11:57 /var/spool/clientmqueue drwxrwx--- 2 51 25 4096 Mar 20 11:57 /var/spool/clientmqueue
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 nis. ---- I would imagine other people with both Solaris and RHEL4 boxes running from the same NIS could be in trouble with this.
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).
I am sorry, but I can not change the uid or gid for smmsp in RHEL. Closing as "not a bug".