Well, the submitter spoke about some mal code sent to somebody, who calls it and the LaTeX file does something really bad.
As far as I know, foreign files can't do anything *really* bad. As distributed, TeX will only write files (via \openout) under TEXMFOUTPUT (if set) or the current directory, not to arbitrary paths. And of course it only has current-user privileges, anyway. And it won't run arbitrary processes, either (\write18 is disabled by default), either. As for reading, I don't see a problem in this scenario. Fine, so this foreign document can read /etc/passwd, and you process it and the output contains a nicely (horribly) typeset version of /etc/passwd. As long as you don't blindly post the output on the web for all to see, I see no problem here. Nothing TeX does will get the information to anyone but you, and you already had permission to read it. The time I can see reading being a problem is in a TeX "preview" web page scenario, where people can upload arbitrary documents or insert arbitrary code. In this case, setting openin_any=p makes all the sense in the world. (I doubt it is sufficient, but at least it is a start.) Perhaps you can condense the above into a couple of sentences for texmf.cnf :). normally I don't read very long documnents before processing them.... I don't either, but I don't see a problem with it. Agreed. Where can I find the docs for texmf.cnf? I would either add text to the `Runtime options' node in the Web2c manual, or add a new node `Security' as the last section of the `Installation' chapter, depending on how much we have to say. The individual options of texmf.cnf aren't systematically documented anywhere but in the file itself -- the `Runtime options' node is all there is. (I don't think it makes sense to put this kind of information where the syntax of texmf.cnf is discussed, which is in the Kpathsea manual ...) best, karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]