Hello everybody,

I find it useful to have /tmp on a separate partition (especially
in a multi-user environment) since some programs create lots of
temporary files. Still, there is also /var/tmp, which is world
writable and thus can also overfill the root partition under some
circumstances. Surely, one can place /var/tmp on a separate
partition, too. But the number of partitions then seems to grow
too much (just MHO). The only idea that comes to my mind is to

# rmdir /var/tmp
# ln -sf /var/tmp /tmp

Does anyone know about possible drawbacks of this solution?
I am running such a configuration for nearly a week now and
face no problems. Still, the more experience the better :-)

Regards,
Mikhail

P.S. I don't like an idea of just automatically cleaning /var/tmp,
say, once a week (as AFAIK RH does). Once I lost a full set of
iso images due to this. I don't want others to find themselves in
a similar situation.

Mikhail Zotov wrote:

> Does anyone know about possible drawbacks of this solution?
> I am running such a configuration for nearly a week now and
> face no problems.**Still,*the*more*experience*the*better*:-)

Seems like a fine idea to me, though I've never tried it myself. I'll point
out though that /var/log and /var/spool can fill up as well. My philosophy
is that when it makes sense to have /tmp on a separate partition, it makes
just as much sense to have /var on one too.

Jeffrey

Jeffrey Froman wrote:
> Seems like a fine idea to me, though I've never tried it myself. I'll point
> out though that /var/log and /var/spool can fill up as well. My philosophy
> is that when it makes sense to have /tmp on a separate partition, it makes
> just as much sense to have /var on one too.

yeah. isn't the more common solution to put /var on a separate partition
and symlink /tmp to /var/tmp?

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

On Fri, 15 Oct 2004 07:38:38 +0000, Joost Kremers wrote:
> Jeffrey Froman wrote:
>> Seems like a fine idea to me, though I've never tried it myself. I'll point
>> out though that /var/log and /var/spool can fill up as well. My philosophy
>> is that when it makes sense to have /tmp on a separate partition, it makes
>> just as much sense to have /var on one too.
>
> yeah. isn't the more common solution to put /var on a separate partition
> and symlink /tmp to /var/tmp?

Probably yes. However i see some possible problems one could encounter
with that setup. One is /var being mounted read-only (as it should be):

~$ su -c "mount |grep -e 'var\|tmp\|home'"
Password:
/dev/hda5 on /tmp type ext3 (rw,nosuid,nodev)
/dev/hda6 on /var type ext3 (rw,noexec,nosuid,nodev)
/dev/hda8 on /home type ext3 (rw,nosuid,nodev)

But some programs expect they can execute one of their temp-files...
If the program honors TMPDIR or TMP environment vars - as it should:

$ cat /etc/profile.d/tmp.sh
#!/bin/sh

if [ ! -d "$HOME/tmp" ]; then
rm -rf "$HOME/tmp"
mkdir -p "$HOME/tmp"
fi

chown "$USER" "$HOME/tmp"
chmod 0700 "$HOME/tmp"

TMPDIR="$HOME/tmp"
TMP="$TMPDIR"
export TMPDIR TMP

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

Should work (FWIW: it does for me) the above protects against shared
"tmp" race conditions on multiuser machines to boot. (As far as apps
honoring $TMPDIR and/or $TMP goes ofcource.)

Another thing might be, when the /var partition gets unmounted somehow
you'd lose the /tmp mount-point (in case that is a symlink). Putting
something like the following in /etc/rc.d/rc.local should do instead:

if [ -d /var/tmp ]; then
echo "Mounting /tmp on /var/tmp"
/bin/mount --bind /tmp /var/tmp -o nodev,nosuid
fi

--
-Menno.

Menno Duursma <pan@desktop.lan> wrote:
>On Fri, 15 Oct 2004 07:38:38 +0000, Joost Kremers wrote:
>> Jeffrey Froman wrote:
>>> Seems like a fine idea to me, though I've never tried it myself. I'll point
>>> out though that /var/log and /var/spool can fill up as well. My philosophy
>>> is that when it makes sense to have /tmp on a separate partition, it makes
>>> just as much sense to have /var on one too.
>>
>> yeah. isn't the more common solution to put /var on a separate partition
>> and symlink /tmp to /var/tmp?
>
>Probably yes. However i see some possible problems one could encounter
>with that setup. One is /var being mounted read-only (as it should be):

Why would anyone mount /var read-only?

/var/lock
/var/log
/var/run
/var/spool
/var/tmp
/var/www

And perhaps others must all be writable.

The best solution that I've found is to make /var a separate
mounted file system, and symlin both /tmp and /usr/tmp to
/var/tmp.

Mounting a separate /tmp is just wasted space. The directory to
mount ro is /usr, not /var.

....

>TMPDIR="$HOME/tmp"
>TMP="$TMPDIR"
>export TMPDIR TMP

Having your own tmp seems fine, but I don't really see any need
for it at all.

>Should work (FWIW: it does for me) the above protects against shared
>"tmp" race conditions on multiuser machines to boot. (As far as apps
>honoring $TMPDIR and/or $TMP goes ofcource.)
>
>Another thing might be, when the /var partition gets unmounted somehow
>you'd lose the /tmp mount-point (in case that is a symlink). Putting
>something like the following in /etc/rc.d/rc.local should do instead:
>
>if [ -d /var/tmp ]; then
> echo "Mounting /tmp on /var/tmp"
> /bin/mount --bind /tmp /var/tmp -o nodev,nosuid
>fi

Unnecessary...

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

Jeffrey Froman <jeffrey@fro.man> wrote in message news:<10mukjff1p874d3@corp.supernews.com>...
> Mikhail Zotov wrote:
>
> > Does anyone know about possible drawbacks of this solution?
> > I am running such a configuration for nearly a week now and
> > face no problems. Still, the more experience the better :-)
>
> Seems like a fine idea to me, though I've never tried it myself. I'll point
> out though that /var/log and /var/spool can fill up as well. My philosophy
> is that when it makes sense to have /tmp on a separate partition, it makes
> just as much sense to have /var on one too.
>
> Jeffrey

Thanks for the reply. I see your point and perhaps you are right.
Still it seems that it's easier for an occasional user to fill
/var/tmp but not /var/log and/or /var/spool, and that's what I am
worrying about.

Regards,
Mikhail

* Floyd L. Davidson <floyd@barrow.com>:
[ ... ]
> The best solution that I've found is to make /var a separate
> mounted file system, and symlin both /tmp and /usr/tmp to
> /var/tmp.

Agreed that it's a good idea to make `/var' a separate filesystem.
However, I've read that it's a bad idea to have `/tmp' a symlink to
`/var/tmp'. Also, that `/tmp' may be cleared at every boot while
`/var/tmp' is not implicitly. Unfortunately, the source of this
information escapes leaving me little to back it up.

I've found this so far:

<http://forums.devshed.com/showpost.php?p=136087&postcount=7>

"Incidentally it also says that while it is tempting to link /tmp to
/var/tmp, this is a bad idea. The reason is that the contents of /tmp
may be cleared by the OS after a reboot, whereas the contents of
/var/tmp will remain."

What I like to do myself is mount `/tmp' as tmpfs (Linux 2.4 and later).
Since `/tmp' is on a memory-based filesystem, it's very fast and is
automatically kept clear across reboots.

Found something that suggests my idea isn't so unusual.

<http://lists.debian.org/debian-user/1996/08/msg01041.html>

"Nope, the way to go is to finally implement a true memory-fs and make
/tmp a mfs. Every other U**x (except HP-UX) does it that way (or has
the option to do it that way)."

--
James Michael Fultz <xyzzy@sent.as.invalid>
Remove this part when replying ^^^^^^^^

On Fri, 15 Oct 2004 03:15:48 -0800, Floyd L. Davidson wrote:
> Menno Duursma <pan@desktop.lan> wrote:
>>On Fri, 15 Oct 2004 07:38:38 +0000, Joost Kremers wrote:

>>> yeah. isn't the more common solution to put /var on a separate partition
>>> and symlink /tmp to /var/tmp?
>>
>>Probably yes. However i see some possible problems one could encounter
>>with that setup. One is /var being mounted read-only (as it should be):
>
> Why would anyone mount /var read-only?

Oops, your right, my bad.
That should have been noexec ...

> The best solution that I've found is to make /var a separate
> mounted file system, and symlin both /tmp and /usr/tmp to
> /var/tmp.

I don't have any /usr/tmp - non off the apps i'm running seem to need it.
And if you don't care /tmp links into void if /var happens to be unmounted.

> Mounting a separate /tmp is just wasted space. The directory to
> mount ro is /usr, not /var.

Well had you actually *read* some of the parts in my post you snipped:

> /dev/hda6 on /var type ext3 (rw,noexec,nosuid,nodev)
^^^^^^^^^
> /dev/hda8 on /home type ext3 (rw,nosuid,nodev)

> But some programs expect they can execute one of their temp-files...
> If the program honors TMPDIR or TMP environment vars - as it should:

>>TMPDIR="$HOME/tmp"
>>TMP="$TMPDIR"
>>export TMPDIR TMP
>
> Having your own tmp seems fine, but I don't really see any need
> for it at all.

Ah come on, are you trolling?
I know you know this stuff...

>>Should work (FWIW: it does for me) the above protects against shared
>>"tmp" race conditions on multiuser machines to boot. (As far as apps
>>honoring $TMPDIR and/or $TMP goes ofcource.)

Well, basic idee, something like:
http://www.ox.compsoc.net/~swhite/ta...in/node20.html

And there have been some exploits for commen utilities as of late:
http://www.linuxdevcenter.com/pub/a/....html#racecond

(On machines acting as shell server; the OpenWall patch _might_ help too.)

>>Another thing might be, when the /var partition gets unmounted somehow
>>you'd lose the /tmp mount-point (in case that is a symlink). Putting
>>something like the following in /etc/rc.d/rc.local should do instead:
>>
>>if [ -d /var/tmp ]; then
>> echo "Mounting /tmp on /var/tmp"
>> /bin/mount --bind /tmp /var/tmp -o nodev,nosuid
>>fi
>
> Unnecessary...

Read above.

--
-Menno.

James Michael Fultz <xyzzy@sent.as.invalid> wrote:
>* Floyd L. Davidson <floyd@barrow.com>:
>[ ... ]
>> The best solution that I've found is to make /var a separate
>> mounted file system, and symlin both /tmp and /usr/tmp to
>> /var/tmp.
>
>Agreed that it's a good idea to make `/var' a separate filesystem.
>However, I've read that it's a bad idea to have `/tmp' a symlink to
>`/var/tmp'. Also, that `/tmp' may be cleared at every boot while

You are the system admin... if you don't want /tmp cleared, don't
clear it!

>`/var/tmp' is not implicitly. Unfortunately, the source of this
>information escapes leaving me little to back it up.
>
>I've found this so far:
>
><http://forums.devshed.com/showpost.php?p=136087&postcount=7>
>
>"Incidentally it also says that while it is tempting to link /tmp to
>/var/tmp, this is a bad idea. The reason is that the contents of /tmp
>may be cleared by the OS after a reboot, whereas the contents of
>/var/tmp will remain."

Totally irrelevant if you have a competent sysadmin handy.

>What I like to do myself is mount `/tmp' as tmpfs (Linux 2.4 and later).
>Since `/tmp' is on a memory-based filesystem, it's very fast and is
>automatically kept clear across reboots.

That is a distinctly viable route to go. I don't do that, but
it certainly has value (particularly if you have lots of RAM).

>Found something that suggests my idea isn't so unusual.
>
><http://lists.debian.org/debian-user/1996/08/msg01041.html>
>
>"Nope, the way to go is to finally implement a true memory-fs and make
>/tmp a mfs. Every other U**x (except HP-UX) does it that way (or has
>the option to do it that way)."

I've never seen the advantage to that, given the disk caching
and sector buffering that Linux does. In general, physical
writes to /tmp are done at the leisure of the OS, not the user
program. Virtually all user program access is going to be out
of RAM via cache or buffer anyway, so there is not really much
point in putting it into RAM twice.

I haven't researched that at all, and may be all wet.

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

Menno Duursma <pan@desktop.lan> wrote:
>On Fri, 15 Oct 2004 03:15:48 -0800, Floyd L. Davidson wrote:
>> Menno Duursma <pan@desktop.lan> wrote:
>>>Probably yes. However i see some possible problems one could encounter
>>>with that setup. One is /var being mounted read-only (as it should be):
>>
>> Why would anyone mount /var read-only?
>
>Oops, your right, my bad.
>That should have been noexec ...
>
>> The best solution that I've found is to make /var a separate
>> mounted file system, and symlin both /tmp and /usr/tmp to
>> /var/tmp.
>
>I don't have any /usr/tmp - non off the apps i'm running seem to need it.
>And if you don't care /tmp links into void if /var happens to be unmounted.
>
>> Mounting a separate /tmp is just wasted space. The directory to
>> mount ro is /usr, not /var.
>
>Well had you actually *read* some of the parts in my post you snipped:

I can only read what you write, not what you think. And I can't
be expected to sort out conflicts. Frankly, after the first part
I didn't pay much attention to the details because it was
introduced as nonsense. That clearly was a simple typo on your
part, but one with unfortunate significance...

I can certainly see an advantage for servers to have /var
mounted noexec though, and yes that would require something
different. It depends greatly on what kind of exposure the
system has and how secured it has to be.

I should probably modify my comments to take that into account,
and say that for typical home or relatively secured systems
behind a firewall, I see no particular reason not to symlink
/tmp to /var/tmp, which precludes mounting /var noexec. On a
system that is directly accessed by the public, mounting /var
noexec appears to have the higher priority, so a separate /tmp
partition seems in order.

>> /dev/hda6 on /var type ext3 (rw,noexec,nosuid,nodev)
> ^^^^^^^^^
>> /dev/hda8 on /home type ext3 (rw,nosuid,nodev)
>
>> But some programs expect they can execute one of their temp-files...
>> If the program honors TMPDIR or TMP environment vars - as it should:
>
>>>TMPDIR="$HOME/tmp"
>>>TMP="$TMPDIR"
>>>export TMPDIR TMP
>>
>> Having your own tmp seems fine, but I don't really see any need
>> for it at all.
>
>Ah come on, are you trolling?
>I know you know this stuff...
>
>>>Should work (FWIW: it does for me) the above protects against shared
>>>"tmp" race conditions on multiuser machines to boot. (As far as apps
>>>honoring $TMPDIR and/or $TMP goes ofcource.)
>
>Well, basic idee, something like:
>http://www.ox.compsoc.net/~swhite/ta...in/node20.html

I saw nothing there that makes the above necessary.

>And there have been some exploits for commen utilities as of late:
>http://www.linuxdevcenter.com/pub/a/....html#racecond

I saw nothing there that makes the above necessary either.

Granted, it does appear that using a $HOME/tmp would help avoid
making the same mistakes, but it is not going to avoid the problems
listed at those URL's.

>(On machines acting as shell server; the OpenWall patch _might_ help too.)
>
>>>Another thing might be, when the /var partition gets unmounted somehow
>>>you'd lose the /tmp mount-point (in case that is a symlink). Putting
>>>something like the following in /etc/rc.d/rc.local should do instead:
>>>
>>>if [ -d /var/tmp ]; then
>>> echo "Mounting /tmp on /var/tmp"
>>> /bin/mount --bind /tmp /var/tmp -o nodev,nosuid
>>>fi
>>
>> Unnecessary...
>
>Read above.

If /var is not mounted, what point is there in doing anything
other than fixing the problem?

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com