I'll take a stab at mktemp; I was wondering though, if it was strictly necessary to use the system mktemp()... would a similarly functional pike based function work just as well? Where would it best be placed? Stdio?
I can get it done shortly after a little guidance from the Pike style gods.
Bill
The system mktemp is atomical, where a pike variant would get races, and thus probably would be susceptible to more attack vectors on it.
In the last episode (Jul 15), Johan Sundstr÷m (Achtung Liebe!) @ Pike (-) developers forum said:
The system mktemp is atomical, where a pike variant would get races, and thus probably would be susceptible to more attack vectors on it.
There's no such thing as an atomic mktemp(). Use of mktemp() is inherently race-prone, since it simply returns a filename that doesn't exist at the time of the call, and it's up to the application to call open() correctly (i.e. with O_EXCL|O_CREAT to ensure that an attacker's symlink isn't followed), and retry if the open fails. I'd suggest implementing mkstemp() or mkstemps() instead, so you do all the work and return a fd or FILE back to the user.
Ah; I didn't know that there even was a nonatomical system variant; it doesn't seem to make any sense having one that doesn't return the file object. :-)
They didn't get it right on the first try. But the reason mktemp is even mentioned is that we need a tmp-creator that works on all OSs regardless of avilability of atomic syscalls. It would however be prudent to to make one extra function that will fail if it can't do it atomicly.
Um, why do we want a function that fails? It's possible to create a working tmpfile() function (which I suppose is what we really want) without either mkstemp() or mktemp() being available in the libc. The only thing that needs to be available and atomic is open().
Well, I'm also not sure about the availability of mktemp() et al on windows, so I was proposing a functionally equivalent (or superior) alternative written in pike.
On Tue, 15 Jul 2008, Dan Nelson wrote:
There's no such thing as an atomic mktemp(). Use of mktemp() is inherently race-prone, since it simply returns a filename that doesn't exist at the time of the call, and it's up to the application to call open() correctly (i.e. with O_EXCL|O_CREAT to ensure that an attacker's symlink isn't followed), and retry if the open fails. I'd suggest implementing mkstemp() or mkstemps() instead, so you do all the work and return a fd or FILE back to the user.
http://msdn.microsoft.com/en-us/library/aa298503(VS.60).aspx
But there shouldn't be any problems with implementing one in pure Pike.
Good, but to late now for 7.8.1. Don't check anything in until 7.9 has been split off.
As for placing of this function, wouldn't a ->tmpfile() method in the Stdio.File class be best? Similar to ->open() and ->pipe().
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Dan Nelson -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum