Re: [boost] Re: Serialization and tmpnam

From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-07-20 05:51:17

On Tue, Jul 20, 2004 at 05:45:35AM -0400, Miro Jurisic wrote:

> In article <20040720091531.GA34513_at_[hidden]>,
>  Jonathan Wakely <cow_at_[hidden]> wrote:
> 
> > If you can ensure the files are created in a directory that is not group-
> > or world-writeable, or in a directory that has the sticky bit set, then
> > isn't it (relatively) safe to use:
> 
> There is no way to atomically create a directory. The only atomic filesystem 
> modification is file creation; this property of filesystems on UNIX/POSIX is 
> widely known and has numerous consequences, including the use of lock files to 
> implement persistent advisory locking, and many convolutions involving secure 
> temporary files.

Yes, I appreciate that, but if the temp files are created in an existing
directory (say, part of the CVS sandbox) that has the right permissions
then there's no need to create a directory, so it's not a problem that
you can't do so safely.

"Doctor, doctor, when I create directories it causes a race condition."
"Don't create directories then"

The tests could check that the directory where temp files will be
created has suitable permissions and refuse to run if not (although this
should be configurable for people who don't care about security - the
fools! ;)

I don't claim to be an expert on this, and don't know whether it's
possible to use an existing directory, so I'm just thinking out loud.
Apologies if I'm just adding noise.

> The only secure way to use temporary files is to have a function which securely 
> and atomically creates and opens one and returns you the file descriptor, and to 
> use that file descriptor (and not the path/name to the new temporary file) to 
> access the file thereafter. 
> 
> This causes problems because there is no standard way to convert a file 
> descriptor to an iostream (although most vendors have vendor extensions that 
> allow you to do so). This alone should probably be abstracted away in boost, as 
> it's a common request, but even if it isn't, it has to be used for secure 
> temporary files. There is no way around it.

This is a _very_ good candidate for Boost, as everyone has to rely on
incompatible vendor extensions. I'd love to have time to work on it.

jon

-- 
"The tools we use have a profound (and devious!) influence on our
 thinking habits, and, therefore, on our thinking abilities."
	- Edsger Dijkstra