[COMMIT] Import make-temp-name (the functionality of mkstemp(3)) from GNU

[Aidan Kehoe]

 Ar an séú lá déag de mí na Samhain, scríobh Stephen J. Turnbull: 

 > Aidan Kehoe writes:
 > 
 >  >  > Wouldn't it be better to keep the CODING-SYSTEM name and simply document
 >  >  > the additional semantics? I don't think we should encourage use of this
 >  >  > misfeature in application code.
 >  > 
 >  > There's no other way, beyond using write-region-internal--not portable to
 >  > GNU--to access this functionality--avoiding the race condition between
 >  > checking for a file's existence and creating it. It's ugly, but it is a
 >  > positive feature.
 > 
 > I'm not suggesting otherwise.  I'm just suggesting keeping the *name*
 > CODING-SYSTEM.

That’s reasonable enough, and your docstring does that.

 >  > I'm not sure you're clear on the point of the MUSTBENEW argument. To make
 >  > the check-for-an-existing-file-if-it-doesn't-exist-create-it operation
 >  > atomic¹--which it needs to be to avoid security issues for temporary
 >  > files--it needs to be done in the OS kernel. Which means a subr is needed to
 >  > expose it to Lisp.
 > 
 > That could be taken as an argument for implementing make-temp-file in
 > C.  I would prefer that to overengineering `write-region*'.  Are there
 > security implications for other than make-temp-file, 

No.

 > and does anybody actually use this feature on non-temp files?

The existing checks in the rest of the emacs code offer the same
functionality, they just don’t offer the atomic guarantee of the O_CREAT |
O_EXCL combination. 

 >  >  > BTW, do you insist on 'excl (eg, for gagmacs compatibility)? 
 >  > 
 >  > Yes. 
 > 
 > Excuse me while I retch, then.
 > 
 >  > I read that to mean that O_EXCL does have function when O_CREAT isn't set,
 >  > but I admittedly haven't written any code to test that understanding.
 > 
 > I think we'd better, since this is an area with security implications.
 >
 > My understanding FWIW is that the passage you quoted simply documents
 > a possibly astonishing corner case, where there is a dangling symlink.

Yes, from my tests and from looking at vfs_vnops.c, that seems correct.

 > Without O_EXCL, the symlink will be followed and the target file
 > created if it doesn't exist.  With O_EXCL, open(2) notices a directory
 > entry, and errors rather than creating the file.  The man page also says
 > 
 >   O_EXCL          error if create and file exists
 > 
 > and
 > 
 >   [EEXIST]           O_CREAT and O_EXCL were specified and the file exists.
 > 
 > In other words, there is no documented functionality without O_CREAT.

-- 
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpo de la escasez de rinocerontes?