Menno Duursma <pan@desktop.lan> wrote:
>
>Ah come on, are you trolling?
>I know you know this stuff...

This probably should have a separate comment. Don't assume that
I know anything! It has been years since I admin'd anything
either commercial or exposed to the Internet...

To whatever degree I'm up to date on that, it is an accident. I
certainly have no intention of putting any effort into it! I'm
now a retired d00d.

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

On Fri, 15 Oct 2004 05:23:07 -0800, Floyd L. Davidson wrote:
> Menno Duursma <pan@desktop.lan> wrote:

>>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.

Fair enough.

> Frankly, after the first part I didn't pay much attention to the details
> because it was introduced as nonsense.

Sorry about that.

> That clearly was a simple typo on your part, but one with unfortunate
> significance...

Thanks for taking the time to replay and point out my error though.

[ ... ]

>>>>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.

Well, it isn't necessary for the system to work. However it does help to
make temp-race bugs less easy to exploit (for privalige escalation) - in
most cases.

>>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.

To me it seems the best i can do (short of patching /bin/login), in order
to subvert canned atacks against those bugs ATM.

> 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.

It would be better for the bugs to not exist in the first place (ie:
"mktemp") but even then who is to say other software doesn't suffer the
same kind of errors?

As an example, some of the scripts i wrote automating administration tasks
which _have_ to run under UID 0 to work, aren't using temporary files in a
secure manner - should those files reside in a directory writeable by
any other user... Setting TMP to ~/tmp makes them relatively save to use
as far as i can tell.

It seems the shared /tmp concept on Unix is sufficiently prone to
programming error (or hard to use correctly if you will) some Linux
distros went and included PAM modules: http://www.openwall.com/pam/

(Now i don't particularly like PAM. Which is one of the reasons i use
Slackware instead. However IIUC it could provide the option of setting
"per user" quotas even for temp-files (which is another matter ofcource.))

--
-Menno.

Mikhail Zotov wrote:

> 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

That will leave you with a dangling symlink: /tmp/tmp

What you *meant* to write was:

rmdir /var/tmp
ln -s ../tmp /var

(Note that the relative path makes it possible to mount the disk on
another system, perhaps for maintenance, repair, upgrade, forensics,
or whatever other reason, and still get the expected result)

> Does anyone know about possible drawbacks of this solution?

None to my knowledge. I've been doing it for years.

Others have pointed out that it's probably more common practice to have
/tmp symlink to /var/tmp, which I've also done (on non-Linux systems)
for years, but I prefer the separate /tmp: I don't need to backup /tmp,
but I do want to backup /var (mail and printer spools, system logs, etc)

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Floyd L. Davidson wrote:

> Mounting a separate /tmp is just wasted space.

Some, including myself, would disagree with such an absolute statement.

It's perhaps a series of tradeoffs:

1) at the expense of some disk space, I need less tape space (for
backups). Disk space is cheaper, therefore that's a price I'm
willing to pay.

2) at the expense of some disk space, I make it less likely that a user
will accidentally prevent my system from being able to store system
logs, accept new mail, provide printing service, etc. This doesn't
address the malicious user who might arrange to fill up /var on
purpose, but accidents are more likely on my systems than malicious
users.

The point is that there is no absolutely correct way to set stuff like
this up. You have to examine what benefits various approaches will
offer, and make a decision based on your own set of priorities.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Floyd L. Davidson wrote:
> I can only read what you write, not what you think. And I can't
> be expected to sort out conflicts.

c'mon. this is what menno wrote:

first he says /var should be mounted read-only:

> 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):

then he lists his mounted filesystems, where /var is clearly rw:

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

and then he gives the reason why he thinks /tmp shouldn't be linked to
/var/tmp:

> But some programs expect they can execute one of their temp-files...

i know you're retired, but surely you can work out *this* conflict? ;-)

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

Joost Kremers <joostkremers@yahoo.com> wrote:
>Floyd L. Davidson wrote:
>> I can only read what you write, not what you think. And I can't
>> be expected to sort out conflicts.
>
>c'mon. this is what menno wrote:
>
>first he says /var should be mounted read-only:
>
>> 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 waste time looking at the rest of the detail...

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

Floyd L. Davidson wrote:
> Why waste time looking at the rest of the detail...

because someone might have made a typo?

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

Joost Kremers <joostkremers@yahoo.com> wrote:
>Floyd L. Davidson wrote:
>> Why waste time looking at the rest of the detail...
>
>because someone might have made a typo?

So? He corrected it, and we go on from there...

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

> > > Why waste time looking at the rest of the detail...
> >
> > because someone might have made a typo?
>
> So? He corrected it, and we go on from there...

http://members.tripod.com/~goodwin_2/law.html

~Mik

--
....for in the files of /mnt/doom, another string was made...

* Floyd L. Davidson <floyd@barrow.com>:
[ ... ]
>>`/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!

That is true except that it may be the default behavior of the init
scripts to clear `/tmp' during boot. However, this is not the case for
Slackware.

>><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.

I don't understand what you mean. It doesn't seem to have anything to
do with sysadmin competency... Unless the sysadmin goes symlinking
`/tmp' to `/var/tmp'. I think that the idea is that `/tmp' and
`/var/tmp' serve similar yet different purposes. I understand that this
is certainly true, historically.

The early years of Unix, `/tmp' was part of `/' which resided on a small
but relatively fast disk. While `/usr/tmp' was a part of `/usr' which
resided on a significantly larger disk than `/' but was slower. Large
temporary files were written to `/usr/tmp'. sort would use `/usr/tmp',
for instance.

[ `/tmp' on a memory backed filesystem ]
> 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).

It can also be a way to recover otherwise unused swap space since Linux
tmpfs will use swap. I have 512MB of RAM and 1GB of swap. Though I
have `/tmp' mounted as tmpfs, it is an exceptional case that swap is
ever used. Really, it's unusual for more than less than half of memory
to be in use, not counting buffers and cache.

> 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.

I may be wrong, but I think that Linux may be smart enough not to waste
buffers and cache on tmpfs.

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