Harald Koenig <[EMAIL PROTECTED]> writes: > Hi, > > using 20030112 pretest, dvips can't write output to pipes anymore: > > turtle fdp > dvips -Php11 Protokoll_Regelkom_021217.dvi -o '| lp -dhp11' > This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com) > ' TeX output 2003.01.16:1546' -> | lp -dhp11 > /usr/local/teTeX/bin/dvips: ! couldn't open output pipe > > and > > turtle fdp > dvips -Php11 Protokoll_Regelkom_021217.dvi -o '! lp -dhp11' > This is dvips(k) 5.92a Copyright 2002 Radical Eye Software (www.radicaleye.com) > ' TeX output 2003.01.16:1546' -> ! lp -dhp11 > /usr/local/teTeX/bin/dvips: ! couldn't open output pipe
> pretest 20021116 still was ok (can print), > but 20021216 already is broken and has the same problem... The same sort of brokenness is prevalent in RedHat-8.0's binary. I presume that some mistaken sense of security is the cause: if somebody is able to smuggle in a "|badprogram" into the command line, he'll also be able to smuggle in what it takes to let it take action. If the output file could be specified from within the DVI file, things would be different, but I can't for the life of it make sense of why this should be more secure? Suppose that dvips is run in some sort of spoolern with priviledges and you want to avoid having a user call some program by that way. But you never should then let the user transfer a file name by itself, or he could equally maliciously specify /etc/passwd as the target file. I just don't get it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
