Re: Linux libc5 'bug' in mkstemp().

[casper () HOLLAND SUN COM (Casper Dik)]

> Pardon me if this is already known -- Theo, at least, had never heard of a
> Unix doing this.
>
> mkstemp() under Linux claims to conform to BSD4.3, but BSDs (FreeBSD and
> OpenBSD, at least) seem to have a slightly different behavior.  Under Linux,
> new files are created with mode 0666, while under BSDs new files are created
> with mode 0600.  A user need only set his umask to 0 and he will be able to
> write to temp files created with mkstemp() by suid root programs, unless the
> suid root programs set their own umask.  This is probably not a major
> problem for any apps, but it's something everyone should note when porting
> security-sensitive apps to Linux from BSDs (and possibly other platforms).

On Solaris, mkstemp() uses a 0600 parameter as well.  This seems to
be the rpoper thing to do.


It is interesting to note that tmpfile() *MUST* use mode 0666; even though
a file exists only fr a very short while, standard compliance tests
include the honoring of the umask as part of the tests.

Solaris 2.6 tmpfile() was changed to use mkstemp(), but it needs to
fchmod() afterwards for standards complaince. Originally, mkstemp()
was changed to use mode 0666 during development, but I quickly got them
to mend their ways.

Solaris 2.6 tmpfile() does perform the unlink() *before* the fchmod(),
so there's no way anyone will ever get to read/write your temporary
file.

More importantly, tmpfile() is not safe in most SV derived implementations.
Solaris 2.x tmpfile() isn't safe until release 2.6; I'm pretty
sure that AIX and IRIX tmpfile() aren't safe either; at least, they
weren't safe back then.

Casper