9

Using the shared /tmp directory is known to have lead to many security vulnerabilities when predictable filenames have been used. And randomly generated names aren't really nice looking.

I am thinking that maybe it would be better to use a per user temporary directory instead. Many applications will use the TMPDIR environment variable in order to decide where temporary files goes.

On login I could simply set TMPDIR=/temp/$USER where /temp would then have to contain a directory for each user with that directory being writable to that user and nobody else.

But in that case I would still like /temp to be a tmpfs mountpoint, which means that the subdirectories would not exist after a reboot and need to be recreated somehow.

Is there any (de-facto) standard for how to create a tmpfs with per user subdirectories? Or would I have to come up with my own non-standard tools to dynamically generate such directories?

Improve this question
2
  • 1
    I now found that Ubuntu has /run/user which looks almost like what I was looking for (except that /run by default can only use 1/5 the space that other tmpfs are allowed to). Commented Mar 25, 2015 at 14:55
  • If you want more room in /run/user then probably mount -o remount,size=larger% /run/user/uid should work, though, if on ubuntu, you'll probably want to escalate with sudo for that. Commented Mar 25, 2015 at 17:11

3 Answers 3

Reset to default
7

You can use pam-tmpdir for this. It creates a directory for each user that logs in, at the start of their PAM session.

See How to remount filesystem at logout? for a little more context...

In Debian, Ubuntu and derivatives it's available in libpam-tmpdir.

Improve this answer
8
  • Defaulting to /tmp/user for the location does not fully meet my requirements. so at the very least I'd have to reconfigure it to use a different path. I suppose that means there isn't another standard location for this kind of thing, and I'd have to make up my own idea about what path to use. Commented Mar 25, 2015 at 13:57
  • It's actually /tmp/user/$UID, so each user gets their own directory. Commented Mar 25, 2015 at 14:00
  • Sure, but it is still possible for somebody to grab the name /tmp/user before root. Commented Mar 25, 2015 at 14:01
  • If you want to avoid that, you can configure libpam-tmpdir to fail by specifying "required" instead of "optional", which prevents login in an unsafe context. root gets /tmp/user/0, not /tmp/user. Commented Mar 25, 2015 at 14:02
  • I'd still rather have it use a location, where that possibility doesn't even exist. That would be the case if I used /run rather than /tmp. It turns out that /run/user already exists and is created in a way quite similar to what I am looking for. Commented Mar 25, 2015 at 14:20
1

You can just put it in /etc/fstab. A line for a particular user might look like:

tmpfs /home/username/tmp tmpfs size=[num]%,uid=[num],gid=[num],noauto,user,mode=0700

Putting a line like that for each user you want to be able to mount a tmpfs in their home directory will make it so. The user username could do just do mount ~/tmp to mount a tmpfs over their home directory ~/tmp at a 10% current system memory capacity. The mode is set to 0700 so only that user (and root of course) can do anything with the contents of that mount. And the mount is not made automatically - the user has to request it.

You'll want to replace all of that for the relevant values. For example, for yourself you might do:

tmpfs /home/kasperd/tmp tmpfs size=25%,uid=1000,gid=1000,noauto,user,mode=0700 0 1

...if your user and group id are both 1000.

Improve this answer
2
  • 2
    I could imagine that mounting it on a sub directory of home directory could lead to security issues if the user replace the mount point with a symlink. It also doesn't scale well with multiple users. And getting it to work together with ecryptfs could be tricky. Commented Mar 25, 2015 at 18:07
  • 1
    @kasperd - Suit yourself - I don't understand where you're going with any of that. All of the things you mention should just work - you can have mountpoints of different kinds in the same tree - mounting a tmpfs to an ecryptfs shouldn't be any issue at all. Replacing a mount-point w/ a symlink won't give anyone else access to the mountpoint if its mode is 0700. And it will scale just as well as you can script it - it's a simple script, though, just comparing lines in fstab to registered ~. You can get more elaborate of course, but I don't see the need. Commented Mar 25, 2015 at 18:31
1

As of 2024 (although it seems to have been around since 2006), polyinstantiation of /tmp is supported using pam_namespace that comes as part of Pluggable Authentication Modules (PAM):

The pam_namespace PAM module sets up a private namespace for a session with polyinstantiated directories. A polyinstantiated directory provides a different instance of itself based on user name, or when using SELinux, user name, security context or both. If an executable script /etc/security/namespace.init exists, it is used to initialize the instance directory after it is set up and mounted on the polyinstantiated directory. The script receives the polyinstantiated directory path, the instance directory path, flag whether the instance directory was newly created (0 for no, 1 for yes), and the user name as its arguments.

Main configuration is by namespace.conf:

The /etc/security/namespace.conf file specifies which directories are polyinstantiated, how they are polyinstantiated, how instance directories would be named, and any users for whom polyinstantiation would not be performed.

Red Hat provides an example of use: https://www.redhat.com/en/blog/polyinstantiating-tmp-and-vartmp-directories

Another stackexchange question indicates that using polyinstantiated /tmp may break some software: Fix Polyinstantiation of /tmp causing 'connect /tmp/.X11-unix/X0: No such file or directory'

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.