Re: $HOME in loadpath - Re: Getting ready to put out a 4.6 release candidate

[Ethan A M. <sf...@us...>]

Petr Mikulik <mi...@ph...> wrote 
>
>

I see three separate issues here.
I will re-arrange your post to answer them.


> I see the following problem which leads to failure of "make":
> 
> make[2]: Entering directory 
> `/home/mikulik/work/Software/gnuplot/gnuplot/tutorial'
> if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript 
> GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg1.plt ; else gnuplot eg1.plt ; 
> fi
> if test -x ../src/gnuplot ; then GNUPLOT_PS_DIR=../term/PostScript 
> GNUPLOT_LIB=. GNUTERM=latex ../src/gnuplot eg2.plt ; else gnuplot eg2.plt ; 
> fi
> "/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
> during intialization
> 
> WARNING: Error during initialization
> 
> I think it would be better to avoid $HOME/.gnuplot completely during "make", 
> but allow anything during ordinary gnuplot use.

Issue 1:

I would go even further, and say that it should not be necessary to 
run gnuplot in order to "make" gnuplot.

The failure you see comes specifically from doing a "make" in the 
PostScript tutorial subdirectory.  I agree that this shouldn't be part of
the default set of "make" targets, but it has been since forever.
To avoid rebuilding the tutorial on every make, you have to do  
"./configure --without-tutorial". I have that in my default build script.  
But then you can't build it later on even if you want to, so yes, 
it is a bug in the build system.

I think the tutorial should just be an optional make target, similar to
the various optional targets in the ../docs or ../demo directories.  
Then it would not require a special option in ./configure.  
It would not be recreated by "make", only by "make tutorial".  


Issue 2:
> set loadpath "`echo $HOME`/foo"
> 
> I don't know any other way how to get the home dir there (except for 
> GNUPLOT_LIB via shell's rc script); the "~" is not expanded.

By coincidence, I ran into the same issue myself just a couple of
days ago.  So I fixed it.   As of yesterday, both "set loadpath"
and "set fontpath"  call gp_expand_tilde().   I don't know why they have
not always done so - perhaps it was just an oversight.



Issue 3 (this is the major one):
> 
> Even worse, it fails even during gnuplot start-up:
> 
> $ ./gnuplot
> 
>         G N U P L O T
>         Version 4.5 patchlevel 0    last modified 2012-01-05 
>         Build System: Linux i686
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2011
>         Thomas Williams, Colin Kelley and many others
> 
>         gnuplot home:     http://www.gnuplot.info
>         mailing list:     gnu...@li...
>         faq, bugs, etc:   type "help FAQ"
>         immediate help:   type "help"  (plot window: hit 'h')
> "/home/mikulik/.gnuplot", line 3: Pipes and shell commands not permitted 
> during intialization
> 
> WARNING: Error during initialization
> 
> I have the following line in my $HOME/.gnuplot:
> set loadpath "`echo $HOME`/usr/lib/gnuplot"
> 
> This seems to be a consequence of
> 2011-12-28  Ethan A Merritt  
>   Do not allow execution of system(), shell, or popen() commands in 
>   the initialization files.
> 
> What's the reason for this change?

In preparation for 4.6, last month I looked through all the configure options.
I was appalled to discover that the option
   --with-cwdrc    check current directory for .gnuplot file,
                   normally disabled for security reasons
did not work, and never did work.  No matter how you set that option, the
program has always looked for an initialization file ./.gnuplot
As the configuration comment states, this is very bad security practice.
It invites "time bombs" left by a malicious user in the expectation that
someday someone will run a program (in this case gnuplot) while their current
directory is set to somewhere, perhaps /tmp, containing the time bomb.
The damage that could be done by such a bomb is of course much worse if the
initialization file can trigger arbitrary shell commands.  So at the same time
I fixed the configuration option, I disabled running shell commands from the
initialization code.

It is true that the "time bomb" scenario is less of a concern for the
initialization file in your home directory than it is for files in other,
shared, directories.  So it would be possible to make a distinction between
what is allowed in ~/.gnuplot and what is allowed in $CWD/.gnuplot or
$GNUPLOT_SHARE_DIR/gnuplotrc etc.  The particular example you showed can
be fixed without this (and has been); can you think of other legitimate
reasons to invoke a shell command from ~/.gnuplot?

	Ethan