Re: [lmi] [lmi-commits] master 5567c43 1/3: Begin to tackle an observed unit-test failure

[Vadim Zeitlin]

On Mon, 17 Aug 2020 01:50:09 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> *nix has a family of /mko*s*temps*/ functions, while ms recommends its own
GC> variant, _mktemp_s().

 This function is "safe" only in a very limited sense used by Microsoft,
i.e. "_s" just means that it won't override the provided buffer, because it
takes its size on input, rather than just assuming that it has the
necessary size. It doesn't deal at all with the "safety from attacker
exploiting race condition in file creation to compromise the program"
aspect, which is an even more serious problem with mktemp() corrected by
mkstemp(), which opens the file atomically.

GC> Or would my use case call for mkdtemp()?

 Unfortunately, mkdtemp() doesn't seem to be available in MinGW.

GC> It looked like it would take so much effort to figure all that stuff
GC> out that I'd be better off using my own (tested) function.

 This function suffers from the same problem as mktemp(), except it's even
worse because it doesn't even try to randomize anything at all.

 Of course, this is probably not very important for the tests, although
even there, in principle, it could be used to overwrite any file to which
lmi has write access to (e.g. /etc/passwd...) by creating a symlink to it
that unique_filepath() would return. But it's not a good idea to use this
function in production code running on multiuser systems. And, in any case,
using it instead of mktemp() just sweeps the problem under the carpet and
doesn't really deal with it at all.

 Again, you might not care about it, but I wanted to mention the problem
just in case you do.

 Regards,
VZ

pgpXi3HA3epFo.pgp
Description: PGP signature