Re: [tlug] join /tmp and /var

[Joe Larabell <larabell@???>]

Hi,

> with critical i meant ONLY things that prevent you from loggin into your
> machine and fixing the problem. everything else is NOT critical.

That's what I meant. I *have* been unable to log into a system before
because the shell decides it needs to write something into /tmp (like a
process ID or some other unnecessary crud) and it dies if the write fails.
And once you get in, you may need an editor. Some editors won't let you
write out files unless they can use /tmp to manage their intermediate
file-fragments. I guess it depends on your tools but I have encountered
major trouble in the past as a result of /tmp going to 100%.

> and you don't need a gui to do that. (if you can't fix that problem
> without a gui, chances are you can't fix the problem at all anyways)

Yeah... But if it happens when I'm working in the GUI then I have the
choice of bailing out and losing everything I was doing, finding another
machine and telnet'ing into the victim machine (assuming telnetd doesn't
try to write something to /tmp and die in the process), hooking up a dumb
terminal to the serial port, or some other bothersome workaround.

> > If the attack involves the creation of lots and lots of log entries, it's
> > the root user doing the writing to the 5% reserve is useless.
>
> true, but again, a seperate /tmp does not help you here.

Logs usually go to /var. If /var and /tmp are seperate, you don't run out
of /tmp when a log writer fills up /var. Plus, unless you clean out /var
from time to time, or have a cron script do it, you will eventually fill
it up even without this hypothetical DOS attack.

> > I believe you can also put /tmp in the swap area (or is it the other way
> > 'round ;-).
>
> i haven't heard of that one, interresting idea,
> or maybe are you thinking of putting /tmp on a ramdisk?

No, I mean having /tmp and swap in the same partition so both can be large
when they need to be (albeit not at the same time) and still minimize the
wastage. I guess in a way it's similar to a ramdisk, in that small amounts
of stuff in a tmpfs will be stored in memory (on virtual pages, which are
mapped to real memory if you have enough real memory to go around). But
the tmpfs pages can be swapped out when the going gets tough so, unlike a
ramdisk, you can have more /tmp than you have total physical memory.

I did some googling and found tmpfs, which lets you mount a filesystem in
virtual memory (ie: on swap). This is probably already in your kernel:

  http://www.linuxhq.com/kernel/v2.4/17-pre5/Documentation/filesystems/tmpfs.txt

The trick for going the other way 'round (ie: a real /tmp partition with
swap writing to /tmp instead of, or in addition to, a seperate partition)
is called a swapfile:

  http://dev.panopticsearch.com/swapfile-notes.html

Actually, I think I had Solaris in mind when I wrote my last post:

  http://www.netsys.com/sunmgr/1995-03/msg00040.html

I recall working on machines before which had /tmp mounted in the swap
area. But it seems my current (Linux) machine just has /tmp as a regular
directory on the root partition. But, then again, the guy who set this
machine up wasn't feeling very creative when he did it, either.

Of course, this could be worse, security-wise, than not partitioning at
all. Because if some runaway process does manage to fill up a tmpfs
mounted file system, that could exhaust your swap space and then your
system WILL die... Miserably...

Anyhow, just for good measure, here's the partitioning mini-FAQ:

  http://kmself.home.netcom.com/Linux/FAQs/partition.html

Partitioning is a very personal thing. It sounds like your reasoning is
just about as good as any others I've heard. I don't think the original
question of whether the soft links from "/" would cause and performance
degredation has been answered yet, though. I'd be interested in knowing
that for other reasons, if anyone knows.

--
Joe Larabell -- Synopsys VCS Support      US: larabell@example.com
http://wwwin.synopsys.com/~larabell/   Japan: larabell@?jp