Re: /tmp on multi-FS set-ups, or: block users from using /tmp?
On 26/05/2012 20:32, Ted Ts'o wrote:
> On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
>> … But that makes me recall a solution to both the /tmp and quota
>> issues I've seen somewhere: use ~/tmp/ instead of /tmp. This
>> way, user's temporary files will be subject to exactly the same
>> limits as all the other his or her files.
>>
>> (Still, we may need to identify the software that ignores TMPDIR
>> and tries to write to /tmp unconditionally.)
>>
>> > (Snark aside, does tmpfs support quotas yet/will it ever?)
>
> These days I'd argue that multi-user is such a corner case that it's
> not worth optimizing for it as far as defaults are concerned. If
> you're trying to run a secure multi-user system, you need to be an
> expert system administrator, keep up with all security patches, and
> even then, good luck to you. (The reality is that these days, no
> matter what OS you're talking about, shell == root. And that's
> probably even true on the most unusably locked down SELinux system.)
>
> What I'd do in that situation is to use per-user /tmp directories,
> where each user would get its own mount namespace, and so each user
> would have its own /tmp --- either a bind-mounted $(HOME)/tmp to /tmp
> if you want to enforce quotas that way, or a separate tmpfs for each
> user --- and then you can specify the size of the per-user tmpfs
> mounted on each user's version of /tmp.
>
> Cheers,
Again, I thought that:
There is a single base directory relative to which user-specific
non-essential (cached) data should be written. This directory is defined
by the environment variable $XDG_CACHE_HOME.
There is a single base directory relative to which user-specific runtime
files and other file objects should be placed. This directory is defined
by the environment variable $XDG_RUNTIME_DIR.
(http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
I think these two definitions cover what most "users" (i.e. *human*
users) would use /tmp for.
--
Jean-Christophe Dubacq
Reply to: