bobd@magnus.ircc.ohio-state.edu (Bob DeBula) (02/14/91)
We are running Ultrix 4.1 on two DEC 5500s and had decided to
do a little work to secure /usr/spool/mail. We changed
permissions on the /usr/var/spool/mail directory to drwxrwxr-x
(775). We knew that we would have to touch a file in
/usr/var/spool/mail for each user and change ownership and
to their ID with read & write permissions (and we did that).
We were loosely modeling what we're doing on the setup
on our HP-UX 7.0 system. We changed ELM so that it had
setgid for "mail". Everything seems to work well *except*
/usr/bin/mail (which has setuid "root" and setgid "kmem").
First question: why setgid "kmem" (suspect it's a leftover
from when "mail" may have had the same UNIX id number)?
/usr/bin/mail seems to hang forever when invoked in this
new configuration. We decided to try changing the group
on /usr/bin/mail to "mail". This apparently allows it
to continue on, but now it doesn't recognize any mail which is
queued (i.e. it just terminates immediately).
It would appear that for some weird reason, /usr/bin/mail
is checking directory permissions on /usr/var/spool/mail
and terminating immediately if it doesn't like what it sees.
Any ideas on why this is so?
/usr/ucb/mail works fine, incidently.
The reason for doing this in the first place was to keep quota
restricted users from using /usr/var/spool/mail as a storage area.
Thanks in advance for any help/enlightenment you may be able to offer.jch@dyfed.rdg.dec.com (John Haxby) (02/16/91)
./usr/bin/mail is setgid kmem because is bases lock time-outs on the load average which is gets from /dev/kmem. [I know this is wrong, it'll be fixed in a possible future release] I don't believe binmail checks the permissions on /usr/spool/mail (or whatever the alias is), but it is fairly careful about the permissions and properties of files that it tries to drop mail in. Basically, the files should be read-write by the owner and no one else and not be links or symlinks, and, of course, the owner should be the intended recipient. There is some fairly horrible code in there to make sure that this is so, otherwise you get some interesting ways of breaking into mail and things when th e mail spool directory is globally writable. It doesn't sounds as though this is the problem though. Have you set things up so that users cannot append mail to their own spool directories? -- John Haxby, Definitively Wrong. Digital <jch@wessex.rdg.dec.com> Reading, England <...!ukc!wessex!jch>
reuss@ni.umd.edu (Karl Reuss) (02/16/91)
In article <1991Feb15.161545.993@hollie.rdg.dec.com> jch@dyfed.rdg.dec.com (John Haxby) writes: >./usr/bin/mail is setgid kmem because is bases lock time-outs on the load >average which is gets from /dev/kmem. [I know this is wrong, it'll be fixed >in a possible future release] I don't believe binmail checks the >permissions on /usr/spool/mail (or whatever the alias is), but it is fairly >careful about the permissions and properties of files that it tries to drop >mail in. What's always bothered me about Ultrix /usr/bin/mail is that after it does all of the wonderfull checking when opening a mailbox, it never checks for errors after a write. Can you guess what happens if your disk is 100 full ? /usr/bin/mail may never write a line of your message, but it exits normally, sendmail never sees there is a problem, and your mail gets black holed with no one being informed. -Karl Reuss