On Thu, 25 Apr 2019 14:59:37 +0200, Martijn van Duren wrote:
> The fchmod line was added by deraadt@ in r1.5 back in 1998, based on
> std conformance mentioned by cas...@holland.sun.com. The texts that
> I've consulted didn't mention anything about permission sets on the
> file and unlinking the f
That diff accidentally removed the unlink() but I'm not convinced
it is a good idead either way as it introduces a race been open and
unlink where another user could open the file, depending on the
caller's umask.
- todd
On Thu, 25 Apr 2019 09:34:47 -0600, Todd C. Miller wrote:
> I think a better approach is to add an internal version of mkstemp(3)
> that takes a permission flag. We can then pass in DEFFILEMODE for
> the permission bits like stdio and avoid the umask and fchmod
> entirely.
Something like this fo
I think a better approach is to add an internal version of mkstemp(3)
that takes a permission flag. We can then pass in DEFFILEMODE for
the permission bits like stdio and avoid the umask and fchmod
entirely.
- todd
Martijn van Duren wrote:
> Is there a sound reason to keep this code here that I'm overlooking
> or can we please remove it?
I'll add that the umask calls make this function unsafe in a threaded program,
which I think is unexpected.
When playing with tmpfile(3) and pledge(2) I found that tmppath is not
enough for tmpfile to succeed, since it needs fchmod support. This is
logical considering the current implementation, but counter-intuitive
with the tmppath pledge.
The fchmod line was added by deraadt@ in r1.5 back in 1998,
