Information
The /tmp directory is a world-writable directory used for temporary storage by all users and some applications.
-IF- an entry for /tmp exists in /etc/fstab it will take precedence over entries in systemd default unit file.
Note: In an environment where the main system is diskless and connected to iSCSI, entries in /etc/fstab may not take precedence.
/tmp can be configured to use tmpfs
tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap unneeded pages out to swap space. It has maximum size limits which can be adjusted on the fly via mount -o remount
Since tmpfs lives completely in the page cache and on swap, all tmpfs pages will be shown as "Shmem" in /proc/meminfo and "Shared" in free Notice that these counters also include shared memory. The most reliable way to get the count is using df and du
tmpfs has three mount options for sizing:
- size : The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.
- nr_blocks : The same as size, but in blocks of PAGE_SIZE.
- nr_inodes : The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.
These parameters accept a suffix k, m or g and can be changed on remount. The size parameter also accepts a suffix %to limit this tmpfs instance to that percentage of your physical RAM. The default, when neither size nor nr_blocks is specified, is size=50%
Making /tmp its own file system allows an administrator to set additional mount options such as the noexec option on the mount, making /tmp useless for an attacker to install executable code. It would also prevent an attacker from establishing a hard link to a system setuid program and wait for it to be updated. Once the program was updated, the hard link would be broken, and the attacker would have his own copy of the program. If the program happened to have a security vulnerability, the attacker could continue to exploit the known flaw.
This can be accomplished by either mounting tmpfs to /tmp or creating a separate partition for /tmp
Solution
First ensure that systemd is correctly configured to ensure that /tmp will be mounted at boot time.
# systemctl unmask tmp.mount
For specific configuration requirements of the /tmp mount for your environment, modify /etc/fstab
Example of using tmpfs with specific mount options:
tmpfs /tmp tmpfs defaults,rw,nosuid,nodev,noexec,relatime,size=2G 0 0
Note: the size=2G is an example of setting a specific size for tmpfs
Example of using a volume or disk with specific mount options. The source location of the volume or disk will vary depending on your environment:
<device> /tmp <fstype> defaults,nodev,nosuid,noexec 0 0
Impact:
By design files saved to /tmp should have no expectation of surviving a reboot of the system. tmpfs is ram based and all files stored to tmpfs will be lost when the system is rebooted.
If files need to be persistent through a reboot, they should be saved to /var/tmp not /tmp
Since the /tmp directory is intended to be world-writable, there is a risk of resource exhaustion if it is not bound to tmpfs or a separate partition.
Running out of /tmp space is a problem regardless of what kind of filesystem lies under it, but in a configuration where /tmp is not a separate file system it will essentially have the whole disk available, as the default installation only creates a single / partition. On the other hand, a RAM-based /tmp (as with tmpfs ) will almost certainly be much smaller, which can lead to applications filling up the filesystem much more easily. Another alternative is to create a dedicated partition for /tmp from a separate volume or disk. One of the downsides of a disk-based dedicated partition is that it will be slower than tmpfs which is RAM-based.