Temporary files

Kevin Day thekevinday at gmail.com
Wed Sep 26 18:29:39 PDT 2007

On 9/25/07, Robert Connolly <robert at linuxfromscratch.org> wrote:
> Hello. There's another topic I don't think I've gotten around to properly.
> Each package can have different ways of dealing with temporary files... some
> write to /tmp, some to /var/tmp, some to $HOME/tmp, some to $TMPDIR, some to
> the current directory, and I'm not sure what else.
> My desktop has an encrypted /home partition, so I mount /tmp, and /var/tmp, as
> tmpfs to keep my temporary files secure from being left in clear text after a
> power failure. It's annoying me to have to think about how each package deals
> with temporary files... like, where are they written to, and what are they
> named.
> Vim creates a .${filename}.swp file in the directory the opened file is
> located if possible, otherwise it creates the .swp file in the current
> directory Vim was executed from if possible, and after that it uses
> $HOME/tmp/ if that directory exists, and after that it uses /var/tmp. I
> assume it will use /tmp after, if /var/tmp doesn't exist. In the case of
> editors, the swap files are not named randomly so that two editors aren't
> writting to the same file at the same time, and so the changes can be
> restored after a power failure. So there are some cases where statically
> named temporary files are better than randomly named temporary files.
> HLFS only has one editor, but it would be nice if all editors use the same
> naming convention, like $TMPDIR/${filename}.vim.swp and
> $TMPDIR/${filename}.kwrite.swp, so each editor can warn you that an unsaved
> edited file exists when you open it based on a simple search. This is a bit
> complicated to implement, but as a first step they should each use the same
> directory to store these files.
> Putting all temporary files in the same directory is my personal goal, for my
> desktop, but I think it would be practical for everyone too. Whether it's
> Vim, Kwrite, GCC/toolchain build files, etc, so this directory can be secured
> with mode=1777, and so you know where to find them.
> This is something a distribution would generally do, but for HLFS I can see
> security considerations in this that are relevent (to me).
> I would personally prefer programs to fail if the temporary file directory
> doesn't exist, or can't be written to, and only use one directory for
> everything. But there are two classes of temporary files: files which do not
> need to be restored, and files that do need to be restored. In a way, all
> temporary files should be recoverable, but then this temporary directory will
> become cluttered with unneeded files. The only way to keep it manageable is
> to add the application name, and maybe the date, to the temp file so it can
> be cleaned manually periodically.
> Is this a worthwhile goal for HLFS? It's important to me personally because of
> my encrypted /home, but I think it's also relevent to clear text systems.
> Implementing this at build time would probably be a ./configure option,
> like --tmpdir=user ($TMPDIR), --tmpdir=system (/tmp), and --tmpdir=both
> ($TMPDIR first, then /tmp). The alternative is to patch applications to use
> the external Mktemp package/program, which would probably be more acceptable
> to upstream maintainers, and modify the Mktemp package as needed.
> Either way, I'd like to hear feedback about this issue. I feel it's an audit
> issue... a bug.
> robert

I have been changing a large number of "standard"/"expected" things on
my system.
My planned approach has been to make /tmp more secure in addition to
whats said above.

I mount /tmp as a tmpfs, then for each
user/service/daemon/server/etc.. there will be a directory in /tmp/
for that user, the /tmp directory will have mode of rwxr-x--x, where
world can only change into the directory, but not read its contents.
Following that a user/service/.. would have their tmp files stores in
a private /tmp/some_name/ under appropriate permissions (rwxr-x---).
Making tmp files completely private.

For a medium->heavy load server, the tmpfs is a bad idea due to space
limitations, even if its Gigabytes of memory.  The approach here would
be to have a separate partition that is mounted only at /tmp/ with as
much space as needed.  Even for small, non-embedded, servers, a
Gigabyte or two of a separate partition would be a good idea to
offload the use of valuable memory as tmp files.

However, for a personal system, the tmpfs method has worked great for
me for quite some time.

If/when I get around to path-hacking large quantities of projects, I
will submit patches so they may be used for the purposes described
above.  Just don't expect me to get around to starting this in the
next month or two.

Kevin Day

More information about the hlfs-dev mailing list