The following short document \documentclass[10pt]{article} \usepackage{amsmath} \begin{document} \[ \array{chars\\0-15:&\Diamond&\Heart} \] \end{document} causes latex to emit the error ! Use of \@array doesn't match its definition. If you reply "q" then it says OK, entering \batchmode and then runs forever. Without \usepackage{amsmath} it emits the same error but quickly runs to completion after you reply "q".
Now, the \array{...} construction is obviously a latex error, and I don't really care about the .dvi output produced. But the "runs forever" part is a real problem. How can I get latex to not get hung up like this regardless of silly document errors? Thanks, -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
John Forkosh wrote: > The following short document > \documentclass[10pt]{article} > \usepackage{amsmath} > \begin{document} > \[ \array{chars\\0-15:&\Diamond&\Heart} \] > \end{document} > causes latex to emit the error > ! Use of \@array doesn't match its definition. > If you reply "q" then it says > OK, entering \batchmode > and then runs forever. Without \usepackage{amsmath} > it emits the same error but quickly runs to completion > after you reply "q".
> Now, the \array{...} construction is obviously a latex error, > and I don't really care about the .dvi output produced. > But the "runs forever" part is a real problem. How can > I get latex to not get hung up like this regardless of > silly document errors? Thanks,
When it rains it pours... the same behavior is also produced by the following short document \documentclass[10pt]{article} \usepackage{amsmath} \begin{document} \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} \[ \left(\begin{array} \] \end{document} which causes latex to emit the error ! LaTeX Error: Illegal character in array arg. and also runs forever in \batchmode after you reply "q". Taking out either the \usepackage or the \renewcommand allows it to quickly run to completion after replying "q". -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
John Forkosh wrote: > The following short document > \documentclass[10pt]{article} > \usepackage{amsmath} > \begin{document} > \[ \array{chars\\0-15:&\Diamond&\Heart} \] > \end{document} > causes latex to emit the error > ! Use of \@array doesn't match its definition. > If you reply "q" then it says > OK, entering \batchmode > and then runs forever. Without \usepackage{amsmath} > it emits the same error but quickly runs to completion > after you reply "q".
> Now, the \array{...} construction is obviously a latex error, > and I don't really care about the .dvi output produced. > But the "runs forever" part is a real problem. How can > I get latex to not get hung up like this regardless of > silly document errors? Thanks,
Are you trying to quit by entering "q"? If so, then you instead need to enter "x" for "eXit":
$ tex This is TeX, Version 3.1415926 (Web2C 7.5.7) **\badcommand ! Undefined control sequence. <*> \badcommand
? ? Type <return> to proceed, S to scroll future error messages, R to run without stopping, Q to run quietly, I to insert something, 1 or ... or 9 to ignore the next 1 to 9 tokens of input, H for help, X to quit. ? x No pages of output.
"q" means "run Quietly", i.e., in batch mode. This causes TeX to ignore errors and slog ahead as best it can, even if its error-recovery approach locks it into an infinite loop.
> The following short document > \documentclass[10pt]{article} > \usepackage{amsmath} > \begin{document} > \[ \array{chars\\0-15:&\Diamond&\Heart} \] > \end{document} > causes latex to emit the error > ! Use of \@array doesn't match its definition. > If you reply "q" then it says > OK, entering \batchmode > and then runs forever. Without \usepackage{amsmath} > it emits the same error but quickly runs to completion > after you reply "q".
> Now, the \array{...} construction is obviously a latex error, > and I don't really care about the .dvi output produced. > But the "runs forever" part is a real problem. How can > I get latex to not get hung up like this regardless of > silly document errors? Thanks,
array sould be used as an environment : \begin{array}{ preamble } chars \\ 0-15: & \Diamond & \Heart \end{array}
>John Forkosh wrote: >> The following short document >> \documentclass[10pt]{article} >> \usepackage{amsmath} >> \begin{document} >> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >> \end{document} >> causes latex to emit the error >> ! Use of \@array doesn't match its definition. >> If you reply "q" then it says >> OK, entering \batchmode >> and then runs forever. Without \usepackage{amsmath} >> it emits the same error but quickly runs to completion >> after you reply "q".
>> Now, the \array{...} construction is obviously a latex error, >> and I don't really care about the .dvi output produced. >> But the "runs forever" part is a real problem. How can >> I get latex to not get hung up like this regardless of >> silly document errors? Thanks,
>When it rains it pours... the same behavior is also produced >by the following short document > \documentclass[10pt]{article} > \usepackage{amsmath} > \begin{document} > \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} > \[ \left(\begin{array} \] > \end{document} >which causes latex to emit the error > ! LaTeX Error: Illegal character in array arg. >and also runs forever in \batchmode after you reply "q". >Taking out either the \usepackage or the \renewcommand >allows it to quickly run to completion after replying "q".
i take it this is something inside your mathtex system? does that emit "q" when it gets an error message from latex? -- seems odd. -- Robin Fairbairns, Cambridge
Robin Fairbairns <r...@cl.cam.ac.uk> wrote: > John Forkosh <j...@please.see.sig.for.email.com> writes: >> John Forkosh wrote: >>> The following short document >>> \documentclass[10pt]{article} >>> \usepackage{amsmath} >>> \begin{document} >>> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >>> \end{document} >>> causes latex to emit the error >>> ! Use of \@array doesn't match its definition. >>> If you reply "q" then it says >>> OK, entering \batchmode >>> and then runs forever. Without \usepackage{amsmath} >>> it emits the same error but quickly runs to completion >>> after you reply "q".
>>> Now, the \array{...} construction is obviously a latex error, >>> and I don't really care about the .dvi output produced. >>> But the "runs forever" part is a real problem. How can >>> I get latex to not get hung up like this regardless of >>> silly document errors? Thanks,
>>When it rains it pours... the same behavior is also produced >>by the following short document >> \documentclass[10pt]{article} >> \usepackage{amsmath} >> \begin{document} >> \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} >> \[ \left(\begin{array} \] >> \end{document} >>which causes latex to emit the error >> ! LaTeX Error: Illegal character in array arg. >>and also runs forever in \batchmode after you reply "q". >>Taking out either the \usepackage or the \renewcommand >>allows it to quickly run to completion after replying "q".
> i take it this is something inside your mathtex system?
Yes, sir, Robin, you nailed it. I was slightly reluctant to mention that since it publicizes a way for anybody to create runaway processes on the mathtex public web service I'm hosting.
> does that emit "q" when it gets an error message from latex?
Yes. After pulling your expression from the ?query_string, it constructs a file latex.tex containing, more or less, actually a little more than... \documentclass[10pt]{article} \usepackage{amsmath} \begin{document} \[ your expression from ?query_string \] \end{document} and another file reply.txt containing just the single byte q and then from within the C program issues, more or less, system("/path/to/latex/latex latex.tex < reply.txt");
> -- seems odd.
The thought is that if a user submits an expression containing some latex syntax error, any .dvi output latex can produce may help him debug his problem.
The easy solution here, as suggested by Scott, is to put an x in reply.txt (or just to omit the "< reply.txt" part). Actually, that's already an option, but q's the current default. Is that a bad idea?
In any event, I need to apply some kind of fix to make the program more robust to "silly user input". I'm actually a little surprised latex (or is it amsmath?) allows this to happen at all. I'd think unpredictable output is okay when input contains errors, but no program should ever let bad input just hang the machine.
Is this a known latex/amsmath behavior? Anybody planning to change it, or any way I can easily fix it? Otherwise, what's my best course of action to fix mathtex? Thanks, -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
John Forkosh wrote: > Robin Fairbairns <r...@cl.cam.ac.uk> wrote: >> John Forkosh <j...@please.see.sig.for.email.com> writes: >>> John Forkosh wrote: >>>> The following short document >>>> \documentclass[10pt]{article} >>>> \usepackage{amsmath} >>>> \begin{document} >>>> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >>>> \end{document} >>>> causes latex to emit the error >>>> ! Use of \@array doesn't match its definition. >>>> If you reply "q" then it says >>>> OK, entering \batchmode >>>> and then runs forever. Without \usepackage{amsmath} >>>> it emits the same error but quickly runs to completion >>>> after you reply "q".
>>>> Now, the \array{...} construction is obviously a latex error, >>>> and I don't really care about the .dvi output produced. >>>> But the "runs forever" part is a real problem. How can >>>> I get latex to not get hung up like this regardless of >>>> silly document errors? Thanks, >>> When it rains it pours... the same behavior is also produced >>> by the following short document >>> \documentclass[10pt]{article} >>> \usepackage{amsmath} >>> \begin{document} >>> \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} >>> \[ \left(\begin{array} \] >>> \end{document} >>> which causes latex to emit the error >>> ! LaTeX Error: Illegal character in array arg. >>> and also runs forever in \batchmode after you reply "q". >>> Taking out either the \usepackage or the \renewcommand >>> allows it to quickly run to completion after replying "q". >> i take it this is something inside your mathtex system?
> Yes, sir, Robin, you nailed it. I was slightly reluctant to mention > that since it publicizes a way for anybody to create runaway processes > on the mathtex public web service I'm hosting.
>> does that emit "q" when it gets an error message from latex?
> Yes. After pulling your expression from the ?query_string, > it constructs a file latex.tex containing, more or less, > actually a little more than... > \documentclass[10pt]{article} > \usepackage{amsmath} > \begin{document} > \[ your expression from ?query_string \] > \end{document} > and another file reply.txt containing just the single byte > q > and then from within the C program issues, more or less, > system("/path/to/latex/latex latex.tex < reply.txt");
>> -- seems odd.
> The thought is that if a user submits an expression > containing some latex syntax error, any .dvi output latex > can produce may help him debug his problem.
> The easy solution here, as suggested by Scott, is to put > an x in reply.txt (or just to omit the "< reply.txt" part). > Actually, that's already an option, but q's the current > default. Is that a bad idea?
> In any event, I need to apply some kind of fix to make > the program more robust to "silly user input". I'm actually > a little surprised latex (or is it amsmath?) allows this > to happen at all. I'd think unpredictable output is okay > when input contains errors, but no program should ever > let bad input just hang the machine.
> Is this a known latex/amsmath behavior? Anybody planning > to change it, or any way I can easily fix it? Otherwise, > what's my best course of action to fix mathtex? Thanks,
Scott Pakin <scott+...@pakin.org> wrote: > John Forkosh wrote: >> The following short document >> \documentclass[10pt]{article} >> \usepackage{amsmath} >> \begin{document} >> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >> \end{document} >> causes latex to emit the error >> ! Use of \@array doesn't match its definition. >> If you reply "q" then it says >> OK, entering \batchmode >> and then runs forever. Without \usepackage{amsmath} >> it emits the same error but quickly runs to completion >> after you reply "q".
>> Now, the \array{...} construction is obviously a latex error, >> and I don't really care about the .dvi output produced. >> But the "runs forever" part is a real problem. How can >> I get latex to not get hung up like this regardless of >> silly document errors? Thanks,
> Are you trying to quit by entering "q"? If so, then you instead need > to enter "x" for "eXit":
> $ tex > This is TeX, Version 3.1415926 (Web2C 7.5.7) > **\badcommand > ! Undefined control sequence. > <*> \badcommand
> ? ? > Type <return> to proceed, S to scroll future error messages, > R to run without stopping, Q to run quietly, > I to insert something, > 1 or ... or 9 to ignore the next 1 to 9 tokens of input, > H for help, X to quit. > ? x > No pages of output.
> "q" means "run Quietly", i.e., in batch mode. This causes TeX to ignore > errors and slog ahead as best it can, even if its error-recovery approach > locks it into an infinite loop.
Thanks, Scott. As discussed in preceding reply to Robin, the "q" default was intended to help users "debug" expressions containing latex syntax errors by showing them any .dvi output latex could possibly produce. I guess what I need instead is a "gentler" option to "slog ahead but eXit if locked into a loop". If there's no middle ground between "q" and "x", then I suppose "x" has to become the new default. Is that what you'd recommend? -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
GL <gouail...@gmail.com> wrote: > John Forkosh a ?crit : >> The following short document >> \documentclass[10pt]{article} >> \usepackage{amsmath} >> \begin{document} >> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >> \end{document} >> causes latex to emit the error >> ! Use of \@array doesn't match its definition. >> If you reply "q" then it says >> OK, entering \batchmode >> and then runs forever. Without \usepackage{amsmath} >> it emits the same error but quickly runs to completion >> after you reply "q".
>> Now, the \array{...} construction is obviously a latex error, >> and I don't really care about the .dvi output produced. >> But the "runs forever" part is a real problem. How can >> I get latex to not get hung up like this regardless of >> silly document errors? Thanks,
> array sould be used as an environment : > \begin{array}{ preamble } > chars \\ > 0-15: & \Diamond & \Heart > \end{array}
Thanks, GL, but (see preceding reply to Robin) input like that \array{...} error is coming from a general user population. So telling them "don't submit input containing errors" won't work. The program has to robustly handle any input, with or without errors. -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
Lars Madsen <dal...@rtfsignatureimf.au.dk> wrote: > John Forkosh wrote: >> Robin Fairbairns <r...@cl.cam.ac.uk> wrote: >>> John Forkosh <j...@please.see.sig.for.email.com> writes: >>>> John Forkosh wrote: >>>>> The following short document >>>>> \documentclass[10pt]{article} >>>>> \usepackage{amsmath} >>>>> \begin{document} >>>>> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >>>>> \end{document} >>>>> causes latex to emit the error >>>>> ! Use of \@array doesn't match its definition. >>>>> If you reply "q" then it says >>>>> OK, entering \batchmode >>>>> and then runs forever. Without \usepackage{amsmath} >>>>> it emits the same error but quickly runs to completion >>>>> after you reply "q".
>>>>> Now, the \array{...} construction is obviously a latex error, >>>>> and I don't really care about the .dvi output produced. >>>>> But the "runs forever" part is a real problem. How can >>>>> I get latex to not get hung up like this regardless of >>>>> silly document errors? Thanks, >>>> When it rains it pours... the same behavior is also produced >>>> by the following short document >>>> \documentclass[10pt]{article} >>>> \usepackage{amsmath} >>>> \begin{document} >>>> \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} >>>> \[ \left(\begin{array} \] >>>> \end{document} >>>> which causes latex to emit the error >>>> ! LaTeX Error: Illegal character in array arg. >>>> and also runs forever in \batchmode after you reply "q". >>>> Taking out either the \usepackage or the \renewcommand >>>> allows it to quickly run to completion after replying "q". >>> i take it this is something inside your mathtex system?
>> Yes, sir, Robin, you nailed it. I was slightly reluctant to mention >> that since it publicizes a way for anybody to create runaway processes >> on the mathtex public web service I'm hosting.
>>> does that emit "q" when it gets an error message from latex?
>> Yes. After pulling your expression from the ?query_string, >> it constructs a file latex.tex containing, more or less, >> actually a little more than... >> \documentclass[10pt]{article} >> \usepackage{amsmath} >> \begin{document} >> \[ your expression from ?query_string \] >> \end{document} >> and another file reply.txt containing just the single byte >> q >> and then from within the C program issues, more or less, >> system("/path/to/latex/latex latex.tex < reply.txt");
>>> -- seems odd.
>> The thought is that if a user submits an expression >> containing some latex syntax error, any .dvi output latex >> can produce may help him debug his problem.
>> The easy solution here, as suggested by Scott, is to put >> an x in reply.txt (or just to omit the "< reply.txt" part). >> Actually, that's already an option, but q's the current >> default. Is that a bad idea?
>> In any event, I need to apply some kind of fix to make >> the program more robust to "silly user input". I'm actually >> a little surprised latex (or is it amsmath?) allows this >> to happen at all. I'd think unpredictable output is okay >> when input contains errors, but no program should ever >> let bad input just hang the machine.
>> Is this a known latex/amsmath behavior? Anybody planning >> to change it, or any way I can easily fix it? Otherwise, >> what's my best course of action to fix mathtex? Thanks,
> batchmode and parse the log file
Thanks, Lars, I hadn't thought of that. A little test is showing me that the .log file indeed exists and is readable when the error is reported to the screen. But the "! LaTeX Error: ..." stuff isn't in the .log file at that point, and only appears there >>after<< you reply q or x, which is too late to base the q-or-x decision on. That problem aside, there are two more issues I don't immediately see how to resolve. First, the process created by system("/path/to/latex/latex latex.tex < reply.txt"); is already running. I'd have to put latex to sleep, waiting on a signal issued after parsing the .log file and deciding how to proceed, ...or something like that. Is there some way to do that which doesn't involve modifying latex's source? Second, although I can parse the .log file (if it contains the "! LaTeX Error:" message), how can I distinguish between errors that actually cause infinite loops and "benign" errors?
> and how do you define silly input?
:). Well, the only quantifiable characteristic that concerns me is whether or not input causes latex to hang.
> query: a=b \]\input{/etc/passwd}\[ a=b
Okay, yeah, that too. But mathtex already disables \input, though I'd agree any attempt to hack/crack the host by submitting an expression designed to exploit a vulnerability is also a concern. But besides pulling the plug, I know of no 100% foolproof solution to that general problem. If you've got a more complete list of dangerous \commands, that would be helpful. -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
John Forkosh wrote: > Lars Madsen <dal...@rtfsignatureimf.au.dk> wrote: >> John Forkosh wrote: >>> Robin Fairbairns <r...@cl.cam.ac.uk> wrote: >>>> John Forkosh <j...@please.see.sig.for.email.com> writes: >>>>> John Forkosh wrote: >>>>>> The following short document >>>>>> \documentclass[10pt]{article} >>>>>> \usepackage{amsmath} >>>>>> \begin{document} >>>>>> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >>>>>> \end{document} >>>>>> causes latex to emit the error >>>>>> ! Use of \@array doesn't match its definition. >>>>>> If you reply "q" then it says >>>>>> OK, entering \batchmode >>>>>> and then runs forever. Without \usepackage{amsmath} >>>>>> it emits the same error but quickly runs to completion >>>>>> after you reply "q".
>>>>>> Now, the \array{...} construction is obviously a latex error, >>>>>> and I don't really care about the .dvi output produced. >>>>>> But the "runs forever" part is a real problem. How can >>>>>> I get latex to not get hung up like this regardless of >>>>>> silly document errors? Thanks, >>>>> When it rains it pours... the same behavior is also produced >>>>> by the following short document >>>>> \documentclass[10pt]{article} >>>>> \usepackage{amsmath} >>>>> \begin{document} >>>>> \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} >>>>> \[ \left(\begin{array} \] >>>>> \end{document} >>>>> which causes latex to emit the error >>>>> ! LaTeX Error: Illegal character in array arg. >>>>> and also runs forever in \batchmode after you reply "q". >>>>> Taking out either the \usepackage or the \renewcommand >>>>> allows it to quickly run to completion after replying "q". >>>> i take it this is something inside your mathtex system? >>> Yes, sir, Robin, you nailed it. I was slightly reluctant to mention >>> that since it publicizes a way for anybody to create runaway processes >>> on the mathtex public web service I'm hosting.
>>>> does that emit "q" when it gets an error message from latex? >>> Yes. After pulling your expression from the ?query_string, >>> it constructs a file latex.tex containing, more or less, >>> actually a little more than... >>> \documentclass[10pt]{article} >>> \usepackage{amsmath} >>> \begin{document} >>> \[ your expression from ?query_string \] >>> \end{document} >>> and another file reply.txt containing just the single byte >>> q >>> and then from within the C program issues, more or less, >>> system("/path/to/latex/latex latex.tex < reply.txt");
>>>> -- seems odd. >>> The thought is that if a user submits an expression >>> containing some latex syntax error, any .dvi output latex >>> can produce may help him debug his problem.
>>> The easy solution here, as suggested by Scott, is to put >>> an x in reply.txt (or just to omit the "< reply.txt" part). >>> Actually, that's already an option, but q's the current >>> default. Is that a bad idea?
>>> In any event, I need to apply some kind of fix to make >>> the program more robust to "silly user input". I'm actually >>> a little surprised latex (or is it amsmath?) allows this >>> to happen at all. I'd think unpredictable output is okay >>> when input contains errors, but no program should ever >>> let bad input just hang the machine.
>>> Is this a known latex/amsmath behavior? Anybody planning >>> to change it, or any way I can easily fix it? Otherwise, >>> what's my best course of action to fix mathtex? Thanks, >> batchmode and parse the log file
> Thanks, Lars, I hadn't thought of that. A little test > is showing me that the .log file indeed exists and is > readable when the error is reported to the screen. > But the "! LaTeX Error: ..." stuff isn't in the .log file > at that point, and only appears there >>after<< you reply > q or x, which is too late to base the q-or-x decision on. > That problem aside, there are two more issues I don't > immediately see how to resolve. First, the process created by > system("/path/to/latex/latex latex.tex < reply.txt"); > is already running. I'd have to put latex to sleep, waiting > on a signal issued after parsing the .log file and deciding > how to proceed, ...or something like that. Is there some > way to do that which doesn't involve modifying latex's source? > Second, although I can parse the .log file (if it contains > the "! LaTeX Error:" message), how can I distinguish between > errors that actually cause infinite loops and "benign" errors?
>> and how do you define silly input?
> :). Well, the only quantifiable characteristic that concerns me > is whether or not input causes latex to hang.
don;t run it in a mode that hangs
>> query: a=b \]\input{/etc/passwd}\[ a=b
> Okay, yeah, that too. But mathtex already disables \input, > though I'd agree any attempt to hack/crack the host by > submitting an expression designed to exploit a vulnerability > is also a concern. But besides pulling the plug, I know of no > 100% foolproof solution to that general problem. If you've > got a more complete list of dangerous \commands, that would > be helpful.
classical code injection
well jonathan fine already mentioned this, it is much harder to harden LaTeX than TeX.
as I mentioned run in bachmode (emacs and latexmk does this) and then look in the log.
The safest thing to do might be to run LaTeX in a chrooted environment, but that is not easy to create
I'd just do
latex -interaction=batchmode file.tex
and then parse the log fil. I usally just put the entire log back into the browser and let the user check it. Making nice interfaces to users is quite hard. And some errors just does not make sense to the user.
Lars Madsen <dal...@rtfsignatureimf.au.dk> wrote: > John Forkosh wrote: >> Lars Madsen <dal...@rtfsignatureimf.au.dk> wrote: >>> John Forkosh wrote: >>>> Robin Fairbairns <r...@cl.cam.ac.uk> wrote: >>>>> John Forkosh <j...@please.see.sig.for.email.com> writes: >>>>>> John Forkosh wrote: >>>>>>> The following short document >>>>>>> \documentclass[10pt]{article} >>>>>>> \usepackage{amsmath} >>>>>>> \begin{document} >>>>>>> \[ \array{chars\\0-15:&\Diamond&\Heart} \] >>>>>>> \end{document} >>>>>>> causes latex to emit the error >>>>>>> ! Use of \@array doesn't match its definition. >>>>>>> If you reply "q" then it says >>>>>>> OK, entering \batchmode >>>>>>> and then runs forever. Without \usepackage{amsmath} >>>>>>> it emits the same error but quickly runs to completion >>>>>>> after you reply "q".
>>>>>>> Now, the \array{...} construction is obviously a latex error, >>>>>>> and I don't really care about the .dvi output produced. >>>>>>> But the "runs forever" part is a real problem. How can >>>>>>> I get latex to not get hung up like this regardless of >>>>>>> silly document errors? Thanks,
>>>>>> When it rains it pours... the same behavior is also produced >>>>>> by the following short document >>>>>> \documentclass[10pt]{article} >>>>>> \usepackage{amsmath} >>>>>> \begin{document} >>>>>> \renewcommand{\input}[1]{\mbox{[[$\backslash$input\{#1\} illegal]]}} >>>>>> \[ \left(\begin{array} \] >>>>>> \end{document} >>>>>> which causes latex to emit the error >>>>>> ! LaTeX Error: Illegal character in array arg. >>>>>> and also runs forever in \batchmode after you reply "q". >>>>>> Taking out either the \usepackage or the \renewcommand >>>>>> allows it to quickly run to completion after replying "q".
>>>>> i take it this is something inside your mathtex system?
>>>> Yes, sir, Robin, you nailed it. I was slightly reluctant to mention >>>> that since it publicizes a way for anybody to create runaway processes >>>> on the mathtex public web service I'm hosting.
>>>>> does that emit "q" when it gets an error message from latex?
>>>> Yes. After pulling your expression from the ?query_string, >>>> it constructs a file latex.tex containing, more or less, >>>> actually a little more than... >>>> \documentclass[10pt]{article} >>>> \usepackage{amsmath} >>>> \begin{document} >>>> \[ your expression from ?query_string \] >>>> \end{document} >>>> and another file reply.txt containing just the single byte >>>> q >>>> and then from within the C program issues, more or less, >>>> system("/path/to/latex/latex latex.tex < reply.txt");
>>>>> -- seems odd.
>>>> The thought is that if a user submits an expression >>>> containing some latex syntax error, any .dvi output latex >>>> can produce may help him debug his problem.
>>>> The easy solution here, as suggested by Scott, is to put >>>> an x in reply.txt (or just to omit the "< reply.txt" part). >>>> Actually, that's already an option, but q's the current >>>> default. Is that a bad idea?
>>>> In any event, I need to apply some kind of fix to make >>>> the program more robust to "silly user input". I'm actually >>>> a little surprised latex (or is it amsmath?) allows this >>>> to happen at all. I'd think unpredictable output is okay >>>> when input contains errors, but no program should ever >>>> let bad input just hang the machine.
>>>> Is this a known latex/amsmath behavior? Anybody planning >>>> to change it, or any way I can easily fix it? Otherwise, >>>> what's my best course of action to fix mathtex? Thanks,
>>> batchmode and parse the log file
>> Thanks, Lars, I hadn't thought of that. A little test >> is showing me that the .log file indeed exists and is >> readable when the error is reported to the screen. >> But the "! LaTeX Error: ..." stuff isn't in the .log file >> at that point, and only appears there >>after<< you reply >> q or x, which is too late to base the q-or-x decision on. >> That problem aside, there are two more issues I don't >> immediately see how to resolve. First, the process created by >> system("/path/to/latex/latex latex.tex < reply.txt"); >> is already running. I'd have to put latex to sleep, waiting >> on a signal issued after parsing the .log file and deciding >> how to proceed, ...or something like that. Is there some >> way to do that which doesn't involve modifying latex's source? >> Second, although I can parse the .log file (if it contains >> the "! LaTeX Error:" message), how can I distinguish between >> errors that actually cause infinite loops and "benign" errors?
>>> and how do you define silly input?
>> :). Well, the only quantifiable characteristic that concerns me >> is whether or not input causes latex to hang.
> don't run it in a mode that hangs
Thanks again, Lars, I think that'll have to be the solution (see additional example/remarks at bottom three paragraphs).
>> Okay, yeah, that too. But mathtex already disables \input, >> though I'd agree any attempt to hack/crack the host by >> submitting an expression designed to exploit a vulnerability >> is also a concern. But besides pulling the plug, I know of no >> 100% foolproof solution to that general problem. If you've >> got a more complete list of dangerous \commands, that would >> be helpful.
> classical code injection
> well jonathan fine already mentioned this, it is much harder to harden > LaTeX than TeX.
> as I mentioned run in bachmode (emacs and latexmk does this) and then > look in the log.
> The safest thing to do might be to run LaTeX in a chrooted environment, > but that is not easy to create
Especially not easy when the program runs as a cgi. And it's one thing for me to do that on my host running the public web service, but quite another for users who download the source and run the program on their own machines. Most of them just want to see some math on their web pages, without becoming sysadmins or webmasters. So any feasible solution has to be completely transparent to users.
> I'd just do
> latex -interaction=batchmode file.tex
> and then parse the log fil. I usally just put the entire log back into > the browser and let the user check it. Making nice interfaces to users > is quite hard. And some errors just does not make sense to the user.
Strangely (seems strange to me), -interaction=batchmode still hangs for the following example \documentclass[10pt]{article} \begin{document} \renewcommand{\input}[1]{dummy renewcommand} %%\renewcommand{\sqrt}[1]{dummy renewcommand} %%\renewcommand{\beta}{dummy renewcommand} \[ \left(\begin{array}{cccc}1 & 0 & 0 &0\\0 & 1 %%% \end{array}\right) \] \end{document} whereas just latex example.tex < reply.txt with an x in file reply.txt runs to completion (still has the error, of course, but doesn't hang).
That above example also illustrates the following: if you comment out the \renewcommand{\input} and uncomment either or both of the other \renewcommand's, then latex runs to completion (with the error, of course, but without hanging). So there's some weird side effect specifically with \renewcommand for \input. And that does seem to me like something that somebody (who knows the internals) might want to look at sometime.
Meanwhile, the quickest and easiest fix is to put an x rather than a q in reply.txt (just changing the program's default option is even easier). Actually, changing the documentation is a bit more work, and I'll submit the (trivial) CTAN update when finished. For the time being, anyone reading this and running mathtex on their server should just recompile their cgi with the -DNOQUIET option on the compile line. That's all you need to do (assuming not running in quiet mode always fixes the problem). -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
John Forkosh wrote: > Thanks, Scott. As discussed in preceding reply to Robin, > the "q" default was intended to help users "debug" expressions > containing latex syntax errors by showing them any .dvi output > latex could possibly produce. I guess what I need instead is > a "gentler" option to "slog ahead but eXit if locked into a loop". > If there's no middle ground between "q" and "x", then I suppose > "x" has to become the new default. Is that what you'd recommend?
You wrote that the "q" is coming from an input file, right? So how about having the input file instead be "<Enter><Enter><Enter><Enter><Enter>x<Enter>"? That will let TeX swallow and log five errors before exiting. Even better, you can use "q" but run latex using the timelimit command (http://devel.ringlet.net/sysutils/timelimit/). If mathTeX takes more than, say, five seconds to typeset a simple math expression, then you can probably assume it's stuck in an infinite loop. That'll be good when a jerk like me enters "\def\foo{\foo}\foo" on your site, which causes latex to chug away for a while -- without producing a TeX error or even writing anything to the log file -- before issuing an internal server error.
Scott Pakin <scott+...@pakin.org> wrote: > John Forkosh wrote: >> Thanks, Scott. As discussed in preceding reply to Robin, >> the "q" default was intended to help users "debug" expressions >> containing latex syntax errors by showing them any .dvi output >> latex could possibly produce. I guess what I need instead is >> a "gentler" option to "slog ahead but eXit if locked into a loop". >> If there's no middle ground between "q" and "x", then I suppose >> "x" has to become the new default. Is that what you'd recommend?
Thanks for two excellent suggestions, Scott...
> You wrote that the "q" is coming from an input file, right? So how > about having the input file instead be > "<Enter><Enter><Enter><Enter><Enter>x<Enter>"? That will let TeX > swallow and log five errors before exiting.
Seems obvious now that you've said it, but never occurred to me until you did. A few preliminary tests show that some expressions which lock latex into a loop with "q" still lock it into a loop after six or so <Enter>'s, but two or three (or even four) seem safe. I'll clearly just make it a compile-time -D option, and better determine the maximum safe default later. The most important benefit is for simple syntax errors like \alpha\beta\gamow\delta where a few <Enter>'s let the user see an \alpha\beta\delta image, pointing him to the error more directly than an iimmediate x which shows the user no image at all.
> Even better, you can use > "q" but run latex using the timelimit command > (http://devel.ringlet.net/sysutils/timelimit/). If mathTeX takes more > than, say, five seconds to typeset a simple math expression, then you > can probably assume it's stuck in an infinite loop. That'll be good > when a jerk like me enters "\def\foo{\foo}\foo" on your site, which > causes latex to chug away for a while -- without producing a TeX error > or even writing anything to the log file -- before issuing an internal > server error.
This is also a terrific idea that I'll implement as a -D compile option for users who want to use timelimit and can install it on their hosts. My preliminary tests work fine from the command line, but are behaving a little weirdly from within a running program when issued as system("/path/to/timelimit -t10 -T5 /path/to/latex input.tex < reply.txt"); with or without the "< reply.txt" part, which may be being eaten by timelimit. I'll just write a small program to better trace what's going on, which I'm sure will resolve any problems.
Your "\def\foo{\foo}\foo" kinds of problems won't be an issue, as I'll also be disabling a bunch of dangerous \directives (list supplied by Steve Mayer -- thanks). But since \renewcommand seems to have its own dangers (sometimes causing syntax errors to lock latex in a loop), I'll now handle all command disabling from the C program, which should be a third solution to the "latex locked in a loop" problem that started this thread.
Thanks again, Scott, and also everyone else who replied. -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
On Aug 7, 8:08 am, John Forkosh <j...@please.see.sig.for.email.com> wrote:
> Thanks, Scott. As discussed in preceding reply to Robin, > the "q" default was intended to help users "debug" expressions > containing latex syntax errors by showing them any .dvi output > latex could possibly produce. I guess what I need instead is > a "gentler" option to "slog ahead but eXit if locked into a loop". > If there's no middle ground between "q" and "x", then I suppose > "x" has to become the new default. Is that what you'd recommend?
I would send a hundred carriage returns and then x.
But you need more protection anyway because bad documents don't need to generate any error before going into an endless loop!
Donald Arseneau <a...@triumf.ca> wrote: > John Forkosh <please.see.sig.for.email.com> wrote: >> Thanks, Scott. As discussed in preceding reply to Robin, >> the "q" default was intended to help users "debug" expressions >> containing latex syntax errors by showing them any .dvi output >> latex could possibly produce. I guess what I need instead is >> a "gentler" option to "slog ahead but eXit if locked into a loop". >> If there's no middle ground between "q" and "x", then I suppose >> "x" has to become the new default. Is that what you'd recommend?
> I would send a hundred carriage returns and then x.
Thanks, Donald. I've already changed the program so you can compile it with a -DNQUIET=n switch which will then send n returns followed by an x. But I've changed the default from sending q to sending 3 returns and then x. That shows images for simple errors like "\sqrt{123", but stops before any of the examples I gave previously gets locked into a loop. They're all locked into loops by 100 returns.
> But you need more protection anyway because bad documents > don't need to generate any error before going into an endless > loop!
Got any examples besides Scott's "\def\foo{\foo}\foo"? I'll be disabling \def,\newcommand,\etc, so that kind of issue won't be a problem, but I'm no texpert (not even close) and can't even imagine what else might go wrong that I might be able to program around. -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
On Aug 10, 2:01 pm, John Forkosh <j...@please.see.sig.for.email.com> wrote:
> Donald Arseneau <a...@triumf.ca> wrote: > > But you need more protection anyway because bad documents > > don't need to generate any error before going into an endless > > loop!
> Got any examples besides Scott's "\def\foo{\foo}\foo"? > I'll be disabling \def,\newcommand,\etc, so that kind > of issue won't be a problem, but I'm no texpert (not even close) > and can't even imagine what else might go wrong that I might > be able to program around.
There are many possible ways,
\loop\iftrue\repeat
is obvious.
\everypar{\par} or \everypar{\hrule} produce pages without limit, whereas some use of \hrule in a tabular where \par is disabled will silently loop forever.
Furthermore, some "symbols" *require* \def, and you lose them by disabling it.
Donald Arseneau <a...@triumf.ca> wrote: > John Forkosh <j...@please.see.sig.for.email.com> wrote: >> Donald Arseneau <a...@triumf.ca> wrote: >> > But you need more protection anyway because bad documents >> > don't need to generate any error before going into an endless >> > loop!
>> Got any examples besides Scott's "\def\foo{\foo}\foo"? >> I'll be disabling \def,\newcommand,\etc, so that kind >> of issue won't be a problem, but I'm no texpert (not even close) >> and can't even imagine what else might go wrong that I might >> be able to program around.
> There are many possible ways, \loop\iftrue\repeat is obvious. > \everypar{\par} or \everypar{\hrule} produce pages without limit,
Thanks again, Donald. \loop's also on Steve Mayer's "blacklist", and also \everypar, so they shouldn't pose a problem. He's been following this thread (hi, Steve), and asked in email that I not post the complete list. But if you (anybody) are curious and want a copy, it's okay with Steve to email me (john at forkosh dot com) or him (mayer at dial dot pipex dot com) for one.
> some use of \hrule in a tabular where \par is disabled > will silently loop forever. Furthermore, some "symbols" > *require* \def, and you lose them by disabling it.
I'm getting the feeling there's no foolproof solution, and Steve's list may be as good as it's going to get without considerable additional effort. And Scott's timelimit suggestion will hopefully provide a catchall for any pathological expressions that slip through the cracks (I'll be adding that as a mathtex option for users who can install timelimit on their servers). Thanks so much, -- John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
|
