![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |