permissions on /tmp & /var/mail

2007-12-25 8:46:00

        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" <A.J.Thew@liverpool.ac.uk>

pat@rwing.UUCP (Pat Myrto) (he focused also on security mounts,

                            so his response is below)

adap@andrews.edu (Edsel Adap)

Bevin.Steer@UniSA.Edu.Au

Nate Itkin <Nate-Itkin@ptdcs2.intel.com>

Casper Dik <casper@fwi.uva.nl>

danny@ews7.dseg.ti.com (Danny Johnson)

Gautam Das <gautam@bwc.org>

see@uebemc.siemens.de (Seeger Michael)

-------------------------------------------------------------------------------

From: pat@rwing.UUCP (Pat Myrto)

Message-Id: <9404271354.AA28645@rwing.UUCP>

Subject: Re: permissions on /tmp & /var/mail

To: misik@alpha.dcs.fmph.uniba.sk

Date: Wed, 27 Apr 94 6:54:02 PDT

In-Reply-To: <9404261253.AA04426@titan.dcs.fmph.uniba.sk>; 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

runlevel.

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@ole.cdac.com] 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.

E-Mail: Andrej.Misik@fmph.uniba.sk

Comments

Got something to say?

You must be logged in to post a comment.