Re: [Nmh-workers] extensions on tmp filenames?

[David Levine]

Robert wrote:

>   | > >     If the link named by the new argument exists, it shall be removed
>   | > >     and old renamed to new. In this case, a link named new shall
>   | > >     remain visible to other processes throughout the renaming
>   | > >     operation and refer either to the file referred to by new or old
>   | > >     before the operation began.
>   | > >
>   | > > and that's what Linux still uses for its documentation.
> 
> I really cannot believe that anyone is confused by any of this.  The
> documentation is all correct, the operation is all correct, and
> (assuming there are no implementation bugs) nothing has any security
> holes.
> 
> All the documentation quoted above says, is that if you have two
> files A and B and do rename("A", "B") then a file named B is always
> existing and visible (the name A vanishes) through the rename - and
> that as time passes, the name B will initially refer to its old
> contents (nothing surprising there, the rename hasn't happened yet)
> and later will refer to what was in file A, and that anyone that
> opens the file will get one version or the other - depending upon
> exactly when they open.

I agree that that's what we want and it's obvious that all sane
implementations should do that.  But, that contains an ordering
("initially" ... "later") that does not appear in the second
sentence of the documentation excerpt.  That documentation appears
to explicitly disclaim any ordering, given the word choices of
"throughout" and "refer either to".

I wonder why someone even bothered to write that sentence if the
ordered interpretation is correct.  Maybe it was just poorly
written, as Earl noted.  But as it was written, it allowed the
implementation to disclaim ordering.

Even without that, there is an opportuntity for a particular DoS
attack with mkstemp + rename (in pseudocode):

  while true; do
    find /tmp -name 'mhshow??????' -exec touch '{}'.html \;
  done

Sure, we can't prevent all DoS attacks on shared resources.  But
there's no need for us to allow a particular one on the platforms
that have a C library call that does exactly what we want.

> I have no idea what mkstemps() is (I assume some linux invention)

"mkstemps() first appeared in OpenBSD 2.4".  It's available on
current FreeBSD, OpenBSD, Mac OS X, Solaris 11, Linux, and Cygwin.

David