Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 24 Mar 2011 12:24:01 +0100
From: Piotr Meyer <aniou@...tek.pl>
To: owl-dev@...ts.openwall.com
Subject: Re: absolute symlinks

On Thu, Mar 24, 2011 at 11:19:27AM +0300, gremlin@...mlin.ru wrote:
> Link		Points to		Should point to
> 
> /usr/tmp	/tmp			../tmp
> /var/tmp	/tmp			../tmp

FHS suggests that files in /tmp shouldn't be preserved between reboots,
in opposition to /var/tmp/. In different systems this approach varies:

- in RHEL5 /tmp and /var/tmp are separated. Both are cleaned daily from
cron, files in /tmp are deleted after 240 hours, files from /var/tmp:
after 720 hours

- in Debian and Ubuntu /tmp and /var/tmp are separated, /tmp is cleaned
at boot according to TMPTIME variable (0 means 'everything'), /var/tmp
is preserved 

- in NetBSD (ok, this isn't linux distro, but IMVHO sometimes is worth to
know, how things are made in other places) /tmp is often mounted as
small memory-based filesystem and /var/tmp is located in local fs. 
/tmp isn't preserved between reboots (files from memory fs are lost
after unmounting /tmp). /var/tmp isn't cleaned "due to possible race
condition attack based on symlinks"


Personally I prefer some variant of latest approach (tmpfs for /tmp).
Size doesn't matter because if someone needs large temporary space then
always TMP/TMPDIR/TEMPDIR=${HOME}/tmp may be used (been there, done
that). 

With /var/tmp I'm not sure. From one side symlink to /var/tmp is fine
(IMO ordinary users shouldn't preserve temporary files between reboots
outside their's home directories) but, from other side, when root needs
something big to be preserved (and / is relatively small)?

Maybe (yes, it's small revolution and it breaks standard behaviour): /tmp
as tmpfs, /var/tmp as root-only-writeable directory (chmod 700)? 

-- 
Piotr 'aniou' Meyer

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ