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
On Jan 16, Robin Fairbairns wrote:
what os are you using?
there's just been a report (on c.t.t) of this as a direct consequence
of upgrading to rh8.0
I see this problem with SuSE 7.2 running 20030112 (teTeX was built on RedHat 6.2),
and IRIX64-6.5 running beta-20021216.
SuSE 7.3 running
Atsuhito Kohda writes:
Hi,
I am one of tetex maintainers of Debian and we got a bug report
that please include pdftosrc in tetex-bin
It seemed only a slight modification of texk/web2c/Makefile.in
would make pdftosrc. Is there any reason that pdftosrc was not
made by default?
I'm not
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
[added Tomas Rokicki to the recepients, throwing him into this
discussion]
Hi,
-o |lpr no longer works, because the default config file of dvips now
correctly sets secure mode on. Secure mode can be turned off by putting
z0 into a config file for dvips or by specifying -R0 on the commandline
That's a very good point; if the *user* specifices -o |... that
*should* override the security setting.
What if the -o option comes from a config file; should that override
the security setting? Probably not, because the override could
come from a .dvipsrc file created by a malicious program . .
only config files in trusted paths can be used for external commands etc.
Sounds like we're getting closer to Perl's taint mode.
In any case, this is the sort of thing we'd have to depend on
kpathsea to provide, right? I don't see that happening in this
release. Yet, not allowing
o !lpr
I am one of tetex maintainers of Debian and we got a bug report
that please include pdftosrc in tetex-bin
I see. pdftosrc was even included in good-old-teTeX-1.0... I have
just added
@PTEX@pdftosrc = pdftosrc
...tie $(ttf2afm) $(pdftosrc) ...
to texk/web2c/Makefile.in. Seems that this is
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
Dvips has *always* searched in the current directory first for virtually
all files, config files, tfm files, vf files, figure files, header files,
etc. So all the blame on that goes to me. This was intended as a
feature; users sometimes want to override something, much like TeX
searches for
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
Thomas Esser writes:
I am one of tetex maintainers of Debian and we got a bug report
that please include pdftosrc in tetex-bin
I see. pdftosrc was even included in good-old-teTeX-1.0... I have
just added
@PTEX@pdftosrc = pdftosrc
...tie $(ttf2afm) $(pdftosrc) ...
to
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)
Tomas G. Rokicki wrote:
Dvips has *always* searched in the current directory first for virtually
all files, config files, tfm files, vf files, figure files, header files,
etc. So all the blame on that goes to me. This was intended as a
feature; users sometimes want to override something,
Okay, so if we agree the solution is:
1. Allow the output pipe to be opened in all cases
and
2. Never search for configuration files (config.ps, config.printer,
and .dvipsrc are the only ones critical here) in the current
directory
then I've got some questions about dvips vs
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
Date: Thu, 16 Jan 2003 22:39:18 +0100
From: =?ISO-8859-1?Q?Giuseppe_Ghib=F2?= [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: 20030112 breaks dvips -o |lpr
[and for special backtick, only allow a common set of commands at
a fixed path, e.g. convert from ImageMagick]
For format
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.
Full ACK. Whoever writes such a filter should know what he is doing and
put something like an explicit -f or -o argument into the
Giuseppe == 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
19 matches
Mail list logo
