Temporary files

Robert Connolly robert at linuxfromscratch.org
Tue Sep 25 21:10:09 PDT 2007

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 

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070926/87af7a40/attachment.sig>

More information about the hlfs-dev mailing list