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