Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Solaris permission problem(newbie)



I generally do not use Solaris, but I had forgotten about the 't' bit for the 
temp directories. I therefore stand corrected. 

While /var is normally expected to be local, on a cluster or dataless 
system, it will be exported and shared. If shared, there are many files 
that are node specific, so the host OS must be able to allow /var to be 
shared (between systems) with some files and directories to be specified 
as node-specific. Additionally, some subdirectories on /var are normally 
shared on large systems. /var/spool/mail is commonly NFS exported by 
the central mail server, but /var/mqueue is normally local. Gets 
complicated. 
On 28 Apr 2000, at 8:41, Mike Bilow wrote:

> I don't know what book you're reading, but /tmp and /var/tmp damn well
> ought to be mode 1777 or everyone on the system can become root.
> Especially on a Solaris machine where the exploit is well known and
> publicly available, allowing anything other than 1777 is a recipe for
> disaster.  While we're on this subject, /tmp and /var/tmp had also better
> be owned by root.root, or similar kinds of bad things will occur.
<snip>
> In general, you should not be able to run out of space in /var.  The
> difference between /var and /usr is that /var is always understood to be
> local (that is, not NFS).  If you need scratch space, you can define a
> mount point below /var.  This is common for security reasons, such as

Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org