[NTG-pdftex] [ pdftex-Feature Requests-87 ] In case of fatal errors, delete the output file
Feature Requests item #87, was opened at 2004-07-02 11:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros)
Assigned to: Martin Schröder (oneiros) Summary: In case of fatal errors, delete the output file
Initial Comment: When pdfTeX currently encounters a fatal error, it closes it's output file, which leads to incomplete/corrupt files. pdfTeX should produce only valid files, and in case of fatal errors the output should be deleted. ----------------------------------------------------------------------
Comment By: Martin Schröder (oneiros) Date: 2005-12-19 00:38
Message: Logged In: YES user_id=421 The attached patch unlinks the current file, if a fatal error happens. Currently this is done without any checks, and may be a security problem. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 14:35 Message: Logged In: YES user_id=1608 When you truncate a file, the result is an empty file. From a user's viewpoint, that is not the same thing as a corrupt PDF. The distinction is small, but the advantage of an empty file is that it is not likely to be confused for a correct PDF. If it is possible, then deleting the PDF file is definately better, but file deletion doesn't always work. Truncation almost always does work, and it's only two syscalls extra, so why not? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-07-02 14:21 Message: Logged In: YES user_id=421 Simply truncating a pdf still makes it invalid (because the file structure is incomplete). Producing a valid truncated output file in case of fatal errors will be tricky and not always possible. Deleting the corrupt output is much easier. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 13:50 Message: Logged In: YES user_id=1608 If deleting the file doesnt work, truncation is probably still better than nothing. (?) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106
On 2005-12-19 05:08:18 +0530, noreply@sarovar.org wrote:
Initial Comment: When pdfTeX currently encounters a fatal error, it
closes it's output file, which leads to
incomplete/corrupt files.
pdfTeX should produce only valid files, and in case of
fatal errors the output should be deleted.
----------------------------------------------------------------------
Comment By: Martin Schröder (oneiros) Date: 2005-12-19 00:38
Message: Logged In: YES user_id=421
The attached patch unlinks the current file, if a fatal
error happens. Currently this is done without any checks,
and may be a security problem.
The patch does this: if (outputfilename) { xfclose(pdffile, makecstring(outputfilename)); unlink (makecstring(outputfilename)); } How safe is this? And how safe is this for TeX security wise? And is there a better way? Best Martin -- http://www.tm.oneiros.de
Hello, On Mon, Dec 19, 2005 at 01:01:19AM +0100, Martin Schröder wrote:
The attached patch unlinks the current file, if a fatal
error happens. Currently this is done without any checks,
and may be a security problem.
The patch does this:
if (outputfilename) { xfclose(pdffile, makecstring(outputfilename)); unlink (makecstring(outputfilename)); }
How safe is this? And how safe is this for TeX security wise? And is there a better way?
Perhaps it is more safe, if pdfTeX deletes the file only if it
was successfully opened for writing before to ensure that the
file that pdfTeX removes was generated by pdfTeX before.
Yours sincerely
Heiko
Heiko Oberdiek writes:
Hello, On Mon, Dec 19, 2005 at 01:01:19AM +0100, Martin Schröder wrote:
The attached patch unlinks the current file, if a fatal
error happens. Currently this is done without any checks,
and may be a security problem.
The patch does this:
if (outputfilename) { xfclose(pdffile, makecstring(outputfilename)); unlink (makecstring(outputfilename)); }
How safe is this? And how safe is this for TeX security wise? And is there a better way?
Perhaps it is more safe, if pdfTeX deletes the file only if it was successfully opened for writing before to ensure that the file that pdfTeX removes was generated by pdfTeX before.
For portability, use remove(3) instead of unlink(2). If the file came out of xfopen, then we're already assured that pdftex opened it for writing, so it should definitely be ours to remove. I don't see security issues here (they'd have to be dealt with at the point where the file is opened). -- Olaf Weber (This space left blank for technical reasons.)
On 2005-12-19 21:58:42 +0100, Olaf Weber wrote:
For portability, use remove(3) instead of unlink(2). If the file came
Ah yes. Done.
out of xfopen, then we're already assured that pdftex opened it for writing, so it should definitely be ours to remove. I don't see security issues here (they'd have to be dealt with at the point where the file is opened).
Good. Btw: exit(3) or abort(3)? Best Martin -- http://www.tm.oneiros.de
Martin Schröder writes:
On 2005-12-19 21:58:42 +0100, Olaf Weber wrote:
For portability, use remove(3) instead of unlink(2). If the file came
Ah yes. Done.
out of xfopen, then we're already assured that pdftex opened it for writing, so it should definitely be ours to remove. I don't see security issues here (they'd have to be dealt with at the point where the file is opened).
Good. Btw: exit(3) or abort(3)?
abort(3) means "leave core dump" on many platforms. -- Olaf Weber (This space left blank for technical reasons.)
participants (4)
-
Heiko Oberdiek -
Martin Schröder -
noreply＠sarovar.org -
Olaf Weber