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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc12517.3060...@free.fr
