[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mounting /tmp from fstab



On Thu, Feb 24, 2000 at 06:50:33PM -0500, Jonathan Lupa wrote:
> Thanks all, I'll just follow this advice below.  Where in the boot
> chain should this go? Currently, I'm adding it to
> /etc/init.d/bootmisc.sh.

hmm?  the chmod is permanent, just like when you chmod any other
directory on a unix like filesystem the permissions don't go away on
reboot, they are permananent, same is true for /tmp (so long as its a
unix like filesystem like ext2) 

just make sure you use permissions 1777 

[eb@socrates eb]$ ls -ld /tmp/
drwxrwxrwt    4 root     root         1024 Feb 24 07:25 /tmp/
[eb@socrates eb]$

the 1 is the sticky bit (the t ) which prevents users from deleting
files they don't own.

> Tertiary question - why nosuid on /var or /home?  Don't some programs
> leave some stuff in /var (vgetty comes to mind), and shouldn't you
> allow users to set sticky bits on their own stuff?  It doesn't make
> much difference on this machine since it is my desktop, but I'd like
> to know for future reference. :) 

/var is more questionable for nosuid since some (imo broken) stuff
keeps suid binaries there, my system has no such packages installed
there are no set[ug]id files anywhere in /var so i can mount it nosuid
and not have to worry about any suid root shells being hidden away in
the all too many world writable directories there.

note that the s bit is NOT the sticky bit the sticky bit shows up as a
t in the last character of the permissions (see /tmp) the sticky bit
is only relevant on directories.  normally users who have write
permission to a directory may delete any file in that directory
regardless of whether they own the files or have any permission to the
files, that is not always desireable (/tmp and any other world
writable place) setting the sticky bit changes this behaviour to only
allow a user to delete a file if 1) they own it or 2) they own the
directory. nosuid has no effect whatsoever on the sticky bit.

> Thanks again!

no problem

-- 
Ethan Benson

Attachment: pgpzo1aecDKPj.pgp
Description: PGP signature


Reply to: