SUMMARY: permissions on /tmp & /var/mail

From: Andrej Misik (
Date: Thu May 05 1994 - 03:08:35 CDT

        Hi managers!

        My original question:

> We have a problem about permissions on directories /tmp
> and /var/mail
> 1) /tmp
> It is mounted on swap and its permissions look like this:
> $ ls -ld /tmp
> drwxrwxrwx 4 root root 246 Apr 26 14:43 /tmp
> $ mount | grep tmp
> /tmp on swap read/write on Mon Apr 25 16:11:02 1994
> Why is not the sticky bit set? Currently, every user can remove
> any file from /tmp ! Can I cause any trouble if I'll do
> "chmod 1777 /tmp" ?
> 2) /var/mail
> Is there any reason to have /var/mail with permissions
> "drwxrwxrwt" (1777) ? What do you reckon about removing
> write permission for "others"? (chmod o-w /var/mail)
        1) /tmp
           Everybody (except Danny Johnson) suggested to set sticky bit
           on /tmp immediately. I shut down machine to single user mode,
           do "umount /tmp; ls -aldF /tmp" and the result was

           drwxrwxrwt 6 sys sys 2995 May 4 15:59 /tmp/

           So I mounted swap back on /tmp and do
           "chown sys /tmp; chgrp sys /tmp; chmod 1777 /tmp".
           It was several days ago and everything works fine.
           It is also needed to put these commands into /etc/rc?.d/* files,
           because swap is recreated with each reboot.

        2) /var/mail
           The only one problem is with Mail User Agents, such as "elm",
           "mailtool", etc. If you look at ${OPENWINHOME}/bin/mailtool,
           /bin/mail etc., it belongs to "mail" group and is SET-GID.
           So I done the same to elm, and we had no problems with it.....
           ......until I tried to read mail under ULTRIX (we have
           shared mail spool dir between ULTRIX and SOLARIS machines).
           Since there is no "mail" group under BSD, I simply let it
           "1777". Besides, everybody told me mode 1777 on /var/mail
           is normal. But mode "775" is much more secure.
        Many, many thanks to all who responded!

"Mr. A.J. Thew" <>
pat@rwing.UUCP (Pat Myrto) (he focused also on security mounts,
                            so his response is below) (Edsel Adap)
Nate Itkin <>
Casper Dik <> (Danny Johnson)
Gautam Das <> (Seeger Michael)

From: pat@rwing.UUCP (Pat Myrto)
Message-Id: <9404271354.AA28645@rwing.UUCP>
Subject: Re: permissions on /tmp & /var/mail
Date: Wed, 27 Apr 94 6:54:02 PDT
In-Reply-To: <>; from "Andrej Misik" a
t Apr 26, 94 2:53 pm
Status: RO
I dunno why they aren't set (it is not uncommon for stuff to ship or
install with lousy permissions), but I would edit the rc files and where
temp is mounted or set up, add a line to make sure they are set as
you desire. On SunOS 4.1.x, grep /etc/rc* for 'tmp' and look for
the lines that clean up tmp (usually removes it, and recreates it)
and add the chmod 1777 /tmp to it. IN the case of /var/mail,
just set it, as it is not recreated during the boot. For Solaris 2.x,
it would probably be in the /etc/rc?.d subdirs, depending on the
Most systems seem to have lousy permissions as shipped, like /etc
being owned by bin instead of root, and I saw one SysVr2 that
installed with / being set to mode 777.
For SunOS 4.1.x, a patch script was issued because the FCS tape was
created with the WRONG permissions and ownership all over the thing.
I dunno if such a script exists for Solaris 2.x or not.
Places like /etc need to be owned by root, not bin, since on nfs mounts,
root maps to nobody, but other UIDs map to their real UIDs. That
means someone who mounted it could access it as bin, cp passwd
to another file, edit it, delete passwd and move the new version
to its place, if he can become bin on the client machine. Places
with files that should only be edited by root should be OWNED
by root, meaning the subdirs. One cannot just willy nilly do a
chown root *, though because there are some SUID programs that
run SUID to other than root. Its got to be done on a file-by
file and dir-by dir basis. Same with perms, doing a chmod <whatever> *
is a bad idea, too. But definitely set the sticky bits on /tmp,
/var/tmp, and /var/spool/mail (or wherever mail is).
Good luck. Just use common sense and go slow, watching for things
breaking when you clean up the permissions.

pat@rwing  [If all fails, try:  rwing!]  Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.


greetings, miso.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:00 CDT