Date: Wed, 21 Oct 1998 10:45:25 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio mktemp.c Message-ID: <199810210245.KAA14596@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 21 Oct 1998 02:28:35 %2B1000." <199810201628.CAA15294@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> >> Yes, any change breaks:
> >>
> >> /*
> >> * Prevent even ourself from easily accessing the tmp file except
> >> * via the fd returned by mkstemp(). Dont ask why :-).
> >> */
> >> umask(0777);
> >> fd = mkstemp(foo);
> >
> >man mkstemp:
> > The mkstemp() function makes the same replacement to the template and
> > creates the template file, mode 0600, returning a file descriptor opene
d
> > ^^^^
> > for reading and writing. This avoids the race between testing for a
> > file's existence and opening it for use.
>
> man creat. It's not clear that creation has its English meaning or the
> technical one of creat. I trust the code more than the man page.
What does this have to do with creat()? The documentation is the
definition for the interface in this case and here's specific: the file
will be created mode 0600. There is no ambiguity.
> >A specfic mode is specified, your example is broken, especially on NFS.
> >The way to implement what you want is:
> >
> > fd = mkstemp(foo);
> > unlink(foo);
>
> This has a race between the mkstemp() and the unlink().
So? It's no different to another process doing a chmod on the mode 000
file to get access to it. If you want to stop signals from making you
touch the file behind your back, then do what tmpfile() does, ie: mask all
maskable signals. Or just use tmpfile() and fileno() and be done with it.
> >or, if you want a FILE * in the end, use "fp = tmpfile();"
>
> Hmm. POSIX specifies that tmpfile() shall allocate the fd as fopen()
> does (and that fopen() shall allocate it as open() does). This seems
> to require honouring the umask.
It's irrelevant, the filesystem permissions do not "exist" because there
is no file present at the return of tmpfile().
> >Yes, you are right, nvi is going gaga. However, mkstemp() is still
> >broken, it does not behave as specified. This interface is not one we
> >"own" and we cannot change it.
>
> Who owns it? The Linux (Redhat version mumble) man page says that
> mkstemp() conforms to BSD 4.3 and creates the file with permissions
> 0666. glibc-2.0.5c uses the same O_EXCL open as us except for using
> this insecure mode.
This falls squarely into the '1 million flies can't be wrong' department.
Doing it that way just makes it an already dangerous operation more
dangerous.
> Bruce
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810210245.KAA14596>