Bug 587138 - RHEL5.4 - sendmail does not honor Mprog U=uid:gid option
RHEL5.4 - sendmail does not honor Mprog U=uid:gid option
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sendmail (Show other bugs)
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Jaroslav Škarvada
Depends On:
  Show dependency treegraph
Reported: 2010-04-28 23:03 EDT by Jatin Nansi
Modified: 2013-01-10 21:57 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-21 10:54:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (612 bytes, patch)
2010-04-28 23:05 EDT, Jatin Nansi
no flags Details | Diff
Set real UID to effective UID in smrsh (325 bytes, patch)
2010-05-25 05:16 EDT, Jaroslav Škarvada
no flags Details | Diff

  None (edit)
Description Jatin Nansi 2010-04-28 23:03:22 EDT
Description of problem:

Customer is trying to implement a documented sendmail feature on RHEL5.4.  From /usr/share/doc/sendmail/RELEASE_NOTES:

Allow ``U=user:group'' field in mailer definition to set a default
user and group that a mailer will be executed as.  This
overrides the 'u' and 'g' options, and if the `F=S' flag is
also set, it is the uid/gid that will always be used (that
is, the controlling address is ignored).  The values may be
numeric or symbolic; if only a symbolic user is given (no
group) that user's default group in the passwd file is used
as the group.  Based on code donated by Chip Rosenthal of

The intent is to have sendmail process files that end up being owned by the user and group.  The problem is that the uid does not take, but the gid does.

Bruce Nagel, one of the WTEC HPUX sendmail experts, implemented this feature successfully on HPUX 11.31 with the same version of sendmail as Red Hat.

Testing on Red Hat showed that the uid did not take.

Bruce made a simple change to smrsh  that appeared to fix the issue.   Upstream does not appear to have this fix. 

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

How reproducible:

Steps to Reproduce:

This is a detailed procedure to reproduce the problem where smrsh does not set the uid when U= is set in the mailer definition.

Note 1: No need to recreate the sendmail.cf file using m4. Simply modify the default sendmail.cf file that is distributed with the system, smrsh is the program for the prog mailer (Mprog).

Note 2: Do not use the sm-client for reproducing.

       # mv /etc/mail/submit.cf /etc/mail/submit.cf.orig

Note 3: You will first use the default smrsh program to show the problem. After this you will copy in the smrsh1 program to show the workaround/fix.

1. create a user "ban" and add the following .forward file.

  # cat /home/ban/.forward
    ban, "|tst_it"

  o Verify permissions and ownership on the .forward file

    # ls -lia /home/ban/.forward
     2154954 -rw-r--r-- 1 ban root 15 Apr  6 13:55 /home/ban/.forward

  o Verify permissions and ownership for /home/ban

    # ls -liad /home/ban
      588006 drwx------ 4 ban ban 4096 Apr  6 13:55 /home/ban

2. Create another user (testuser) that we will use for the uid/gid test

 #adduser testuser


3. Add the fix/workaround "smrsh1" program to /usr/sbin

    o smrsh1 is modified copy of smrsh with modifications as detailed
      at the end of the document.  In the source tree (attached to Issue
      tracker, it is:

    o cp smrsh1 /usr/sbin

    o Verify permissions and ownership

      # ls -liad /usr/sbin/smrsh1
        1133618 -rwxr-xr-x 1 root root 81428 Apr  6 14:26 /usr/sbin/smrsh1

4. Modify the sendmail.cf to add the S flag to F= and U=uid:gid to the Mprog mailer definition.

  o cd /etc/mail

  o vi sendmail.cf

  o Change the smrsh mailer for the "F=S..." and the U=.


     Mprog,    P=/usr/sbin/smrsh, F=SlsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
               F=SlsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
               A=smrsh -c $u

   o Do not change the smrsh program to smrsh1 at this time. We first want to see the failure,.

5. Change the permissions to 755 for the /etc/smrsh directory.

  o chmod 755 /etc/smrsh

6. Add the following "tst_it" script to the /etc/smrsh directory.

  o cat tst_it
    rm -f /tmp/mail.out
    read test
    echo $test > /tmp/mail.out
  o chmod 755 tst_it

7. Now to test with sendmail

  # echo tst | sendmail -v ban
    /home/ban/.forward: line 1: forwarding to ban, "|tst_it"
     ban... Connecting to local...
     ban... Sent
     "|tst_it"... Connecting to prog...
     "|tst_it"... Sent

8. Verify uid/gid for the /tmp/mail.out file

    # ls -liad /tmp/mail.out
    2221261 -rw-r--r-- 1 root testuser 61 Apr 21 12:33 /tmp/mail.out

  o Notice that the UID is root and should be testuser

9. Now change the Mprog smrsh to smrsh1

  Mprog,          P=/usr/sbin/smrsh1, F=SlsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
                  F=SlsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
                  A=smrsh -c $u

10. Test to verify fix/workaound

   NOTE: You must remove the /tmp/mail.out file prior or a failure will occur

 o rm /tmp/mail.out

  # rm /tmp/mail.out
  # echo tst | sendmail -v ban
  /home/ban/.forward: line 1: forwarding to ban, "|tst_it"
  ban... Connecting to local...
  ban... Sent
  "|tst_it"... Connecting to prog...
  "|tst_it"... Sent

  # ls -lia /tmp/mail.out
  2221261 -rw-r--r-- 1 testuser testuser 61 Apr 21 12:42 /tmp/mail.out

 Note: Notice the uid is now testuser

Actual results:
/tmp/mail.out is owned by root.

Expected results:
/tmp/mail.out should be owned by testuser.

Additional info:
I have reproduced this issue locally, and tested the patch proposed by the customer. The patch fixes this bug.
Comment 1 Jatin Nansi 2010-04-28 23:05:25 EDT
Created attachment 410010 [details]
proposed patch
Comment 5 Jaroslav Škarvada 2010-05-25 05:16:40 EDT
Created attachment 416330 [details]
Set real UID to effective UID in smrsh

This behaviour is strange, but according to sendmail S flag documentation:

From sendmail documentation for the S flag:
>>S Don’t reset the userid before calling the mailer. This would be 
used in a secure environment where sendmail ran as root. This could 
be used to avoid forged addresses. If the U= field is also specified, 
this flag causes the effective user id to be set to that user.<<

Thus the effective UID is changed and the real UID is not.

From the bash documentation (on RHEL the bash is the default sh and the sh is used for command execution via smrsh):

>>If the shell is started with the effective user (group) id not equal to
the real user (group) id, and the -p option is not supplied, no startup
files are read, shell functions are not inherited from the environment,
the  SHELLOPTS  variable, if it appears in the environment, is ignored,
and the effective user id is set to the real user id.  If the -p option
is  supplied  at  invocation, the startup behavior is the same, but the
effective user id is not reset.<<
Thus the effective UID is changed to root. To change to the requested behaviour it is possible to:
a) Use the "-p" parameter in smrsh code for sh invocation, or 
b) change the real UID to effective UID as proposed in the patch from comment 1. 

From my point of view: in the a) solution the real UID remains set to root (the root privileges can be regained). With the b) solution extra care must be taken by administrator in order not to allow bypassing restricted shell by specific environment/startup files settings for bash.

Thanks for the patch from comment 1, the sligthly simplified version follows.
Comment 6 Jaroslav Škarvada 2010-05-31 05:58:38 EDT
Reported upstream. Waiting for their opinion about the issue and patch.
Comment 7 Jaroslav Škarvada 2010-06-03 08:08:29 EDT
Reply from Neil W. Rickert:

I am just thinking aloud here.

If the proposed patch solves the problem, then that would show that
it is not really a bug at all.  That is, smrsh is getting the euid it
should get, and inspection of the code shows that smrsh is not
changing that euid.

If there is a bug in the sendmail distro, I would think that the bug
is in sendmail itself for setting only the euid and not the ruid.
However, personally I don't see that as a bug.

I think the actual 'bug' is in the linux "/bin/sh", which sets the
euid to the ruid.  I'm sure RedHat does not think that to be an
actual bug, but a safety consideration.

Since 'smrsh' is supposed to be paranoid, setting ruid to euid does
not seem an appropriate thing to do.  Using the 'S' flag on an 'smrsh'
mailer does not seem appropriate.  The intention was for 'smrsh' to be
used with the 'prog' mailer, and it seems a bad idea to use the 'S'
flag with that.

If 'smrsh' is being used for a specialized mailer, then my opinion
would be that a special purpose wrapper be used for that mailer.  If
you happen to be able to create that wrapper by making small mods to
the 'smrsh' code, then I don't see a problem with that.   But I
suggest it be released as a separate wrapper function (maybe
'rhsmrsh') supported by redhat.

Again, I'm just thinking aloud here.  Maybe someone else has a
different idea.

Comment 8 Jaroslav Škarvada 2010-06-03 09:30:46 EDT
According to comment 5 this behaviour is documented, thus it is not a bug. According to comment 7 the upstream opinion is also that it is not a bug thus it is not probable that patch will be integrated. 

Typically, the smrsh is started as the user the mail is for. Most of problems can be solved by setting appropriate permissions on directories/files the user needs to access. Also aliases can be used for specific tasks such as piping to command. If this is still not enough, the customer can use simple (custom) wrapper. The wrapper can drop the root privileges as soon as possible and then perform specific tasks as the required user.

Change in behaviour of smrsh could affect other customers relying on upstream version. Creation and maintenance of specialized smrsh fork can lead to more problems than it solves. So, is it worth to implement it?
Comment 9 Radek Vokal 2010-07-21 10:42:09 EDT
dev_nacking based on comment #8
Comment 10 RHEL Product and Program Management 2010-07-21 10:54:53 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

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