On Mon, Jun 2, 2008 at 11:01 PM, Koji Yokota <[EMAIL PROTECTED]> wrote:
> Jean-Marc Lasgouttes wrote:
>>
>> Therefore the only solution is chroot. We only
>> have to work out how it could be used.
>
> chroot normally needs to be done as a root, so I'm stuck :<
I thought using LD_PRELOAD to disable
Koji Yokota <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Therefore the only solution is chroot. We only
>> have to work out how it could be used.
>
> chroot normally needs to be done as a root, so I'm stuck :<
It looks like it...
JMarc
Jean-Marc Lasgouttes wrote:
Therefore the only solution is chroot. We only
have to work out how it could be used.
chroot normally needs to be done as a root, so I'm stuck :<
Koji
Jean-Marc Lasgouttes wrote:
> > aha. but there is nothing to lose if Koji ask once again ;)
>
> But then we'll need a way to check that the version of gnuplot is
> recent enough.
this is easy, old version of gnuplot fail to run if any else parameter
than file is given. hackish, yes ;)
pavel
Pavel Sanda <[EMAIL PROTECTED]> writes:
> José Matos wrote:
>> > i think that the correct solution would be to request gnuplot devs to add
>> > some special parameter from commandline which disallows to execute any
>> > external programs, either from system() or the plot ">
>> IIRC last time we
José Matos wrote:
> > i think that the correct solution would be to request gnuplot devs to add
> > some special parameter from commandline which disallows to execute any
> > external programs, either from system() or the plot "
> IIRC last time we visited this subject Angus asked this on gnuplo
On Monday 19 May 2008 18:23:55 Pavel Sanda wrote:
>
> i think that the correct solution would be to request gnuplot devs to add
> some special parameter from commandline which disallows to execute any
> external programs, either from system() or the plot " pavel
--
José Abílio
Koji Yokota <[EMAIL PROTECTED]> writes:
> - Whenever gnuplot.py is called it pops up an alert, saying
> it is exposing the system to some risk (and explain it well)
> and urge user to check the gnuplot code
People tend to click OK without reading.
> - gnuplot temp
Jean-Marc Lasgouttes wrote:
> People tend to click OK without reading.
Yes. So, the severity of damage after careless click should not be too
large, at least. The risk in that case would be limited to what users
can do with shell's built-in commands. I wonder if this is still too risky.
>
>>
Koji Yokota wrote:
> Alfredo Braunstein wrote:
> > It's more complicated than that, e.g.
> >
> > gnuplot> plot "
> I could never imagine gnuplot accepts even such expression :o
>
> > Maybe some solution involving a chroot?
>
> Jean-Marc Lasgouttes wrote:
> > The only good solution would be an execu
Alfredo Braunstein wrote:
> It's more complicated than that, e.g.
>
> gnuplot> plot " Maybe some solution involving a chroot?
Jean-Marc Lasgouttes wrote:
> The only good solution would be an execution mode of gnuplot that
> disables calls to system. Last time I checked, it did not exist.
For com
Koji Yokota <[EMAIL PROTECTED]> writes:
> Yeah right... If only shell execution can be a security hall (is this
> right?), we can comment out the related lines from the source file by
> the python script. Anyway the script scans over the source file, doing
> so is rather straightforward.
The only
Koji Yokota wrote:
>> if it finds out
>> the expression "^\s*system" or "^\s*\!", it comments out the related
>> lines.
>
> In addition, "load" function must be skipped because its content is not
> known to gnuplot.py. Also, we must consider the case that multiple
> commands exist in one line
It
if it finds out
the expression "^\s*system" or "^\s*\!", it comments out the related
lines.
In addition, "load" function must be skipped because its content is not
known to gnuplot.py. Also, we must consider the case that multiple
commands exist in one line.
Koji
Helge Hafting wrote:
Ouch.
Could this be solved by having LyX refusing to use gnuplot file
containing the "system" command? Or is it much more complicated?
Helge Hafting
Yeah right... If only shell execution can be a security hall (is this
right?), we can comment out the related lines from t
José Matos wrote:
On Thursday 15 May 2008 16:14:29 Koji Yokota wrote:
I think it should be better checked by professionals, but I hope it is
useful.
How do you think?
Historically the problem with gnuplot was the fact that is has not any
sandboxing scheme.
So it should be possible
On Fri, 16 May 2008, Koji Yokota wrote:
José Matos wrote:
Historically the problem with gnuplot was the fact that is has not any
sandboxing scheme.
So it should be possible to send you a gnuplot file that erases your
home area
if you run gnuplot over it.
Example (this is specific to u
José Matos wrote:
> Historically the problem with gnuplot was the fact that is has not any
> sandboxing scheme.
>
> So it should be possible to send you a gnuplot file that erases your
home area
> if you run gnuplot over it.
>
> Example (this is specific to unix/linux but it can be adapted to ot
On Thu, 15 May 2008, José Matos wrote:
On Thursday 15 May 2008 16:14:29 Koji Yokota wrote:
I think it should be better checked by professionals, but I hope it is
useful.
How do you think?
Example (this is specific to unix/linux but it can be adapted to other
systems):
system("rm -rf ~")
A
On Thursday 15 May 2008 16:14:29 Koji Yokota wrote:
> I think it should be better checked by professionals, but I hope it is
> useful.
>
> How do you think?
Historically the problem with gnuplot was the fact that is has not any
sandboxing scheme.
So it should be possible to send you a gnuplot fi
Hi all,
The attached is a proposal for a new external template for gnuplot, a
graph plotting program. I have been using it for my personal use for a
while, but I thought it may be better included in the main body as it is
convenient.
With this template, users can directly edit the gnuplot source
21 matches
Mail list logo
