COMMAND

    mail(1)

SYSTEMS AFFECTED

    HP-UX 7.0

PROBLEM

    To start with  the background information  you need, this  is what
    /bin/mail looks like:

    -r-xr-sr-x   2 bin   mail  106496 Oct 12  1989 /bin/mail

    The mail spool directory /usr/mail is of course:

    drwxrwxr-x   2 bin   mail   13312 Dec 18 21:11 /usr/mail

    Any mailbox in /usr/mail looks like:

    -rw-rw----   1 root  mail    1444 Dec 18 17:43 /usr/mail/root

    Ok, the  schme for  local mail  delivery is  easy: some  mail user
    agent (mailx, Elm, GNU Emac's RMAIL, ...) calls  /usr/lib/sendmail
    which  in  trun  calls  /bin/mail  (from  now  on  referred  to as
    binmail) for local mail delivery.  Binmail appends to the  mailbox
    in /usr/mail  if it  exists.   No problem.  If the mailbox DOESN'T
    EXISTS,  binmail  creates  it.  Looks  good,  but...  Imagine  the
    following scenario: user  badguy sends a  message to another  user
    victim. User victim doesn't seem  to have a mailbox in  /usr/mail.
    badguy  uses  malix  (any  other  MUA  will  do  [calling  binmail
    directly  also  does  the  trick])  to  compose his message; mailx
    calls sendmail, which  in trun calls  binmail. As soon  as binmail
    runs,  it  runs  with  euid=badguy,  egid=mail.  Binmail   creates
    /usr/mail/victim: this file  is now owned  by badbuy. Now  binmail
    does  a  'chown("/usr/mail/victim",  victim,  mail)'.  However, in
    the meantime (the small amount of time that he owned the  mailbox)
    badguy  could  have  done  anything  he  wanted  with it.  Various
    options surely spring to mind... Experiments showed that in  appr.
    80% of all  cases you're quick  enough to do  something nasty with
    the mailbox.  Running binmail nicely increases this percentage  of
    course. Note that this problem only occurs if the mailbox  doesn't
    exist. Well, why doesn't it exist then? Because some MUA's can  be
    configured to unlink the mailbox if it is empty (GNU's RAMIL  does
    it, mailx might, Elm might).

SOLUTION

    I got around this problem  temporarily by doing the following:  1)
    trying hard to  configure all MUA's  not to remove  the mailbox if
    it is empty. That is really hard, because users can easily  change
    that back in  there own init  files (~/.elm/elmrc, ~/.mailrc)  but
    in that  case they  just have  to blame  themselves. 2) making the
    creation of an empty mailbox with the right permission part of  my
    installing a new user script.