Hi all!
Frank Küster has rewritten texdoc in luatex and now it really works much
better than the original one.
But, we have a problem, the os.tmpname function.
Could you recommend a procedure for creating a temporary DIRECTORY?
os.tmpname already CREATES a file named in the return value, so
tmpdir = os.tmpname();
is_ok_tmpdir,error_string = lfs.mkdir(tmpdir)
does not work.
Furthermore, a call to securly create a tmp dir would be nice, too.
Any suggestion? Or consider this a proposal for what would be nice to
have in luatex ;-)
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
Hi all!
Frank Küster has rewritten texdoc in luatex and now it really works much better than the original one.
Good to here that!
Furthermore, a call to securly create a tmp dir would be nice, too.
I agree, and will happily add it. mkstemp() doesn't help though, as it only works for files. I'll have to borrow or write a version of BSD's mkdtemp, somehow. Best wishes, Taco
Hi Taco, On Sa, 17 Nov 2007, Taco Hoekwater wrote:
Frank Küster has rewritten texdoc in luatex and now it really works much better than the original one.
Good to here that!
Well, searching the whole disk with find when we have ls-R databases was a strange approach, no? The next Debian packages of luatex (as soon as you release a new beta ;-) will ship the lua version of texdoc instead of the default texlive texdoc.
Furthermore, a call to securly create a tmp dir would be nice, too.
I agree, and will happily add it. mkstemp() doesn't help though, as it only works for files. I'll have to borrow or write a version of BSD's mkdtemp, somehow.
The is probably the best idea, since relying on a lib function which
might not exist is a problem.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
Hi all!
Frank Küster has rewritten texdoc in luatex and now it really works much better than the original one.
But, we have a problem, the os.tmpname function.
Could you recommend a procedure for creating a temporary DIRECTORY?
os.tmpname already CREATES a file named in the return value, so
tmpdir = os.tmpname(); is_ok_tmpdir,error_string = lfs.mkdir(tmpdir)
does not work.
maybe it opens a file just to be sure that the name is indeed reserved an dnot taken by another process in tne meantime, so os.tmpdir() is needed; i wonder, maybe it makse sense to accept an optional argument that for the root so that one can generate a tmpdir at a specific location i.e. tmpdir("/tmp") or so Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hi Hans! On Sa, 17 Nov 2007, Hans Hagen wrote:
maybe it opens a file just to be sure that the name is indeed reserved an dnot taken by another process in tne meantime, so os.tmpdir() is
Yes, otherwise it would be racy, some other process could make a symlink attack whatever you have in your home dir.
needed; i wonder, maybe it makse sense to accept an optional argument that for the root so that one can generate a tmpdir at a specific location i.e. tmpdir("/tmp") or so
mkstemp and mkdtemp (section 3)
allow for templates. Or the shell function
mktemp
allows for templates and creation of dirs/files.
But are mkdtemp and mkstemp available everywhere we want to compile
luatex?
The man page of mkdtemp(3) is not very inviting:
VERSIONS
Available since glibc 2.1.91.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
2007/11/17, Norbert Preining
But are mkdtemp and mkstemp available everywhere we want to compile luatex?
The man page of mkdtemp(3) is not very inviting: VERSIONS Available since glibc 2.1.91.
HISTORY A mktemp() function appeared in Version 7 AT&T UNIX. The mkdtemp() func- tion appeared in OpenBSD 2.2. The mkstemp() function appeared in 4.4BSD. The mkstemps() function appeared in OpenBSD 2.3. BUGS For mktemp() there is an obvious race between file name selection and file creation and deletion: the program is typically written to call tmpnam(3), tempnam(3), or mktemp(). Subsequently, the program calls open(2) or fopen(3) and erroneously opens a file (or symbolic link, FIFO or other device) that the attacker has created in the expected file loca- tion. Hence mkstemp() is recommended, since it atomically creates the file. An attacker can guess the file names produced by mktemp(). When- ever it is possible, mkstemp() or mkdtemp() should be used instead. For this reason, ld(1) will output a warning message whenever it links code that uses mktemp(). The mkdtemp() and mkstemps() functions are non-standard and should not be used if portability is required. ------------------ Btw: The OpenBSD man pages are available online. :-) Best Martin
On Sa, 17 Nov 2007, Martin Schröder wrote:
For this reason, ld(1) will output a warning message whenever it links code that uses mktemp().
The mkdtemp() and mkstemps() functions are non-standard and should not be used if portability is required.
Hmm, so there is the option between portability and security, grrrrr.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
On Sa, 17 Nov 2007, Martin Schröder wrote:
Yes. And a case for autoconf. :-(
I am confident Taco will manage this ;-) My acquantaince with auto*
tools is not even 0, better less then 0.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
On Sa, 17 Nov 2007, Martin Schröder wrote:
For this reason, ld(1) will output a warning message whenever it links code that uses mktemp().
The mkdtemp() and mkstemps() functions are non-standard and should not be used if portability is required.
Hmm, so there is the option between portability and security, grrrrr.
That's why I wrote:
I'll have to borrow or write a version of BSD's mkdtemp, somehow.
conf'ing for something that only exists in some specific BSD's is not worth the effort (unless it can reliably be added to openbsdcompat). Best wishes, Taco
2007/11/18, Taco Hoekwater
That's why I wrote:
I'll have to borrow or write a version of BSD's mkdtemp, somehow.
conf'ing for something that only exists in some specific BSD's is not worth the effort (unless it can reliably be added to openbsdcompat).
The original openssh-openbsd-compat has #if !defined(HAVE_MKDTEMP) || defined(HAVE_STRICT_MKSTEMP) int mkstemps(char *path, int slen); int mkstemp(char *path); char *mkdtemp(char *path); #endif Best Martin
Martin Schröder wrote:
2007/11/18, Taco Hoekwater
: That's why I wrote:
I'll have to borrow or write a version of BSD's mkdtemp, somehow. conf'ing for something that only exists in some specific BSD's is not worth the effort (unless it can reliably be added to openbsdcompat).
The original openssh-openbsd-compat has #if !defined(HAVE_MKDTEMP) || defined(HAVE_STRICT_MKSTEMP) int mkstemps(char *path, int slen); int mkstemp(char *path); char *mkdtemp(char *path); #endif
But will this work if a platform has mkstemp, but not mkdtemp? Best, Taco
participants (4)
-
Hans Hagen
-
Martin Schröder
-
Norbert Preining
-
Taco Hoekwater