Re: 20030112 breaks dvips -o |lpr
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
Re: 20030112 breaks dvips -o |lpr
Thomas Esser [EMAIL PROTECTED] writes: That's a very good point; if the *user* specifices -o |... that *should* override the security setting. Good, we agree here. What if the -o option comes from a config file; should that override the security setting? In secure mode, dvips should not trust the dvi file. I don't see why dvips should stop trusting its configuration files. If these are messed up by some other security problem, then the user has lost already. kpsepath dvips_config .:!!/root/texmf/dvips//:!!/usr/local/share/texmf/dvips//:!!/usr/share/texmf/dvips// Bad. Bad, bad, bad. Default TeX security for normal execution prohibits TeX from writing to files in external hierarchies or files starting with `.'. IMO, config files should _never_ be looked for in the default directory. If they aren't, we are pretty safe from Trojans in TeX files. Where is the point in reverting to trickery in order to write stuff to some place where you could write them in the first place if you wanted to? So, I suggest not to disable the output pipe at all (no matter wether it was set by some config file or the command line). So do I. And complain to whoever thought it reasonable to search for config files in `.' (mine is currently provided by RedHat, probably some old teTeX 1.0.7). As long as config files are kept out of areas where TeX processes can write, I don't think it a security problem if one can specify output to a pipe. In particular, since you could in the same place specify output to /etc/passwd. I hope you get my point why I think config files should not be looked for in `.'. That would be great, indeed. I plan to release teTeX-2.0, soon (now that pdftex-1.10a *final* is out). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
Tomas G. Rokicki [EMAIL PROTECTED] writes: What if someone untar's a paper distribution with a dvi file and associated figures, that contains a .dvipsrc file? Or config.ps file? Configuration files should not be searched for in the current directory. I am repeating myself here. And then runs dvips? In this case it's not TeX writing the output file, but we're still enabling an exploit. Now of course someone can do the same thing in general with a .bashrc file or .login file (assuming the user unpacks to the home directory, which is distressingly common). If a user unpacks something into his home directory where all sorts of configuration files are kept, TeX security is the least worry of the user. How about retricting the panicking to those cases where a user is acting in a remotely sane manner? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
Giuseppe Ghibò [EMAIL PROTECTED] writes: Furthermore in output pipe we could have different level of security, so to have both tex users as well as unix sysadmin happy (the latter mainly because dvips is for instance used in some printer filter which could run with root privileges): 1) allow pipe output to any command 2) allow pipe output but only to a fixed set of commands (fixed in the sources and not modifiable in further config files: e.g. only /usr/bin/lp [in case of running cups or SysV] and /usr/bin/lpr). Too contrived, IMO. 3) don't allow any output to a pipe, but only to files What's the use of that distinction? If I can write any file I have access to, I don't need no fscking pipe to do my harm in the first place. 4) don't allow any output to a pipe Or one considers certain options security relevant and won't accept them from a file in a TeX-writable place (. or below or so). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: 20030112 breaks dvips -o |lpr
Giuseppe Ghibò [EMAIL PROTECTED] writes: 2) protect the system when dvips run as root as filter. The filters should have options to let all the pipes disabled. Don't see the necessity. root filters (like in line spoolers) are run in separate directories and with command line options specified by the filter programmer. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Stack size limit?
Date: Wed, 11 Sep 2002 18:58:39 +0200
From: Thomas Esser [EMAIL PROTECTED]
I found that the following ditty which in earlier incarnations of my
system just died almost immediately with a Segmentation Fault, will
under current 2.4 Linux kernels under, say, RedHat's (null) beta,
cause the machine to more or less freeze:
tex '\def~{\if~}~'
My system (linux with 2.4.19 kernel) get slower, but tex is stopped with
! TeX capacity exceeded, sorry [main memory size=251].
after a few seconds.
Which is very much harmless, no issue with that. For small settings
of the stack ulimit, this might also have segfaulted fast, what I
experienced previously and with which I don't have a problem, either.
But if you write \number instead of \if you should get to see the
unmitigated original problem, as I checked now. Please pass this on
to the web2c maintainer, I had just reported this from memory, and \if
seems to have another brake built in. With \number, on _this_ system
(not the one I am writing this mail on, logged in there remotely), the
Linux OOM killer got active and pulled the plug on the TeX process --
good decision. But it might also have decided to pull the plug on the
X Server instead. This will not cause any problem unless the stack
size ulimit is rather large or unlimited, which unfortunately seems to
be the default on my Laptop (newest RedHat).
That's bad. So perhaps one should let TeX automatically set a stack
size limit, roughly what
ulimit -s 1024 or so would do.
There are always ways to do weired things and to bring the system down
unless you set up limits that make the system unusable. I don't think
that adding such a system dependency is worth the trouble.
Well, I would consider it worth the trouble in cases where this may
affect system stability.
Anyway, the maintainer of web2c should decide that (since I aim to
follow him as closely as possible), so I'll forward him your
request.
I agree. Please pass on this letter as well, if it is not too much
trouble and if he is not reading the pretest list.
--
David Kastrup Phone: +49-234-32-25570
Email: [EMAIL PROTECTED] Fax: +49-234-32-14209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Re: Omega+teTeX
Date: Fri, 30 Aug 2002 10:07:06 -0400 (EDT)
From: Alan Hoenig [EMAIL PROTECTED]
I understand that you are planning to drop Omega from the official
teTeX distribution, and I am writing to urge you to reconsider this
decision. It is frustrating that Yannis Haralambous and John
Plaice are so uncommunicative, but I hope that this is no reason to
discriminate against the software.
It is not discriminated against. Once there is a stable release of
it, it can be included like anything else.
Many people lose interest in their programs, no longer have time,
or even die, but their software continues to live after them. The
current Omega works for me
What current Omega? There are several different releases with
different features and in different states of non-documentation. Who
but the user itself is to decide which of those versions is what will
be working for him?
Of course, even if Omega were not part of teTeX, it is still
readily available. Yet being ``dropped'' somehow confers a badge
of shame or even of illegitimacy that Omega does not deserve.
Get a stable release of it then. The contention with regard to that
is that Yannis and John are of the opinion that the current state is
so temporary that it is not worth either documenting it or developing
a consistent LaTeX interface for this version for lambda.
If you are of a different opinion, feel free to spin off a stable,
documented Omega/Lambda from the development line of Omega where you
find it appropriate. Yannis and John do not consider that worth
doing, and it certainly is above the head of someone like Thomas that
does not even use Omega.
It is cheap demanding that Thomas should do all the work required for
choosing and making a usable fixed point from Omega. I would be
willing to bet that if you volunteered on spearheading an effort of a
stable Omega spinoff, that Thomas would not object.
Moreover, an orphan Omega that is not integrated into teTeX will be
much harder for a na\{\i}ve user---even an experienced user---to
install. For these reasons, I do hope you will reconsider your
decision.
It is hard enough work to collect and arrange stable, released
software supported and documented by their authors. I would rather
have Thomas concentrate on that than trying to second-guess users and
developers of a system where nobody cares enough to provide a useful
release. And that also means you.
If you think I sound like a complete ***, this may be just because
I am, but that does not change the principal problem.
--
David Kastrup Phone: +49-234-32-25570
Email: [EMAIL PROTECTED] Fax: +49-234-32-14209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Re: 2002-08-25 pretest
From: Idris S Hamid [EMAIL PROTECTED] Date: Tue, 27 Aug 2002 07:27:58 -0600 On Sunday 25 August 2002 22:58, Thomas Esser wrote: yesterday, I have uploaded a new teTeX-beta release: snip Omega was removed, mainly for two reasons: - I hardly get any response from John or Yannis is I have a question / problem (about copyright or tecnical stuff, e.g. about the lex problem on Solaris) - the latest Omega releases are not yet stable I might put Omega back as soon as the new release becomes stable. Ok, but what about those of us who use Omega for mission-critical work? And those would be installing the newest beta-test versions of teTeX for what particular reason? Mission-critical and beta-test are not the best match. Why can't you just stick with the last version you shipped, 1.15? Where mission-critical is concerned, I think you yourself are the best judge about what version of Omega might be the most appropriate for you. Get and compile that. Anyway, I think it's very sad seeing Omega removed from teTeX for what may be an indefinite period of time. How about telling that to the Omega developers? -- David Kastrup Phone: +49-234-32-25570 Email: [EMAIL PROTECTED] Fax: +49-234-32-14209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Re: texexec teTeX
Idris S Hamid [EMAIL PROTECTED] writes: Is the texexec.pl script executable? (chmod +x). Just did this. If you specify the complete path name (/usr/TeX/bin/i386-linux/texexec.pl), does it run? Ok, I got it working, though I'm not sure exactly what did it. Here is some more strange behavior: If I'm in root and do texexec, everything works fine. If I'm in my user account and do texexec, everything works fine. If I su to my home directory from root (or su to root from my home dir), then texexec gives the error What do you mean with su to [your] home directory? su is used for changing users, not directories. Assuming that you mean su to a different user id or similar: texexec `texexec.pl' not found. If from here I su back to my home dir (or to root), the error remains. What does echo $PATH tell? What does env|grep ^PATH= tell? Starting a new console works if I don't su anywhere. I have installed the following in /etc/profile.d/texsetup.sh (based on advice from David Kastrup): case :$PATH: in *:/usr/TeX/bin/i386-linux:*) ;; *) PATH=/usr/TeX/bin/i386-linux:$PATH esac This is executed in login shells, but nowhere else. One possibility would be that you need to add export PATH although I really can't believe that PATH would not already be exported. Another would be that you have some settings in ~~/.bashrc that reset the PATH to a fixed value. A third one would be that after doing the change above you have not logged out: the change will only take effect in sessions started after it has been done. A fourth one would be that the permissions of /etc/profile.d/texsetup.sh are set in a way as to make the file unreadable for some users. A fifth one would be that your default shell is not bash or a Bourne shell. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: 2001/12/02 pretest
Thomas Esser [EMAIL PROTECTED] writes: Dear Thomas, just to know, do you plan to add dvipdfm and ttf2pk support in your latest beta? BTW, do you plan also to include the tx/pxfonts (they are GPL) in the main texmf tree? As I've not seen yet them in 20011202 beta. There are other things that I plan to do first. A stable teTeX will not happen before the next web2c release (teTeX-beta currently contains a web2c test release). While we are being nosy... Are there any plans to include Type1 versions of the EC fonts, like cmsuper or so? Or has this already happened? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: finally: new texmf tarball (beta-20011128)
Adrian == Adrian Bunk [EMAIL PROTECTED] writes: Adrian dvips/config/config.ps is that dvips sends generated .ps Adrian files directly to the printer I don't see anything wrong with that, it is a reasonable default behaviour. Whereas generating a .ps file has no reasonable default: the mode to use depends on whether you want to later print the PS on a particular printer, publish it on the web for the sake of downloading and printing, convert it to PDF via ps2pdf and so on. In short, default .ps file creation is an illusion, anyhow. That's my personal opinion, of course. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: \jobname
From: Fabrice Popineau [EMAIL PROTECTED]
Date: 19 Jul 2001 00:39:14 +0200
Before I spend time on it, does anybody knows why :
D:\tmptex latex \input foo.tex
produces foo.dvi
and
D:\tmptex latex \renewcommand\encodingdefault{T1}\selectfont\input foo.tex
produces texput.dvi? Shouldn't jobname be set accordingly to the
first filename \input?
Yes, unless something forces it to be determined at an earlier point
of time. In this case, \selectfont produces diagnostic output that
goes to the log file. The log file has to be opened, and it is named
\jobname.log.
David Kastrup Phone: +49-234-32-25570
Email: [EMAIL PROTECTED] Fax: +49-234-32-14209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
