[I'm posting this to Cooker also because I believe that implicitly doing "source
.${SHELL}rc" when invoking "less" is a very dangerous timebomb...  IMHO]

Al Andersen wrote:
> 
> I had the same problem with my 7.2 system. The way I resolved it was to edit
> /etc/profile and comment out:
> 
> #if [ -x /usr/bin/lesspipe.sh ];then
> #               export LESSOPEN="|/usr/bin/lesspipe.sh %s"
> #fi
> 
> Your mileage may vary :)

MMDV...  unfortunately, this kills the useful stuff within lesspipe.sh, like
automatic handling of different file types.  

More digging...   the problem is the way 'less' pipes <filename> to $LESSOPEN
when the latter starts with "|" (doh! :^)... 

Tried a lot of different things; hopefully I got the results straight...

export LESSOPEN="| /bin/sh --norc /usr/bin/lesspipe.sh %s"
                   ^^^^^^^^^^^^^^
starts a shell which for some reason ignores "--norc" whether specified here or
on the #!/bin/sh line within lesspipe.sh...


Without the pipe symbol, less invokes "$SHELL -c $LESSOPEN" which makes it
impossible to use --norc here.


export SHELL=/bin/csh
Changing the shell avoids .bashrc; but lesspipe.sh still invokes /bin/sh.  To
change this to '#!/bin/csh' requires rewriting lesspipe.sh...  Adding --norc to
the shebang line does nothing.  Not sure if .cshrc would have the same
problem...


export LESSOPEN="| /bin/cat %s" 
This still invokes .bashrc...


export LESSOPEN="/bin/sh --norc < /usr/bin/lesspipe.sh %s"
export LESSOPEN="|/bin/sh < /usr/bin/lesspipe.sh %s"
export LESSOPEN="|/bin/sh --norc < /usr/bin/lesspipe.sh %s"
These kinda work; but on "q[uit]", "less foo.html" gives:
foo.html: line 1: syntax error near unexpected token `<html>'
foo.html: line 1: `<html>'
starts a shell which for some reason will not accept "--norc" either on the
#!/bin/sh line, or within LESSOPEN...


export LESSOPEN="/bin/sh < /usr/bin/lesspipe.sh %s"
This variation also kinda works; but gives: 
bin/sh: Command not found.


The bottom line is that anything in .bashrc will execute because running "less"
results in implicitly doing a "source .bashrc", not to mention that anything
.bashrc sends to STDOUT is injected into the pipe...  On the whole, this seems
poorly thought out...  though my C skills are quite rusty from lack of use and
old age...  :}

However, creating lesspipe.py and using:
export LESSOPEN="| /usr/bin/lesspipe.py %s" 
avoids the shell timebombs...  here's a Python version (based on LM7.2; 8.0's
lesspipe.sh is much different):

-----------------------------------
#!/usr/bin/env python

import os, sys, re

FILE = sys.argv[1]

TYPE = os.popen("file -L %s | cut -d' ' -f2-" % FILE ).read()

if   re.match('gzip', TYPE):               CMD='gzip -d -c -q'
elif re.match('compress\'d\ data', TYPE):  CMD='uncompress -c'
elif re.match('GNU\ tar', TYPE):           CMD='tar -tvf'
elif re.match('Zip', TYPE):                CMD='unzip -c -qq'
elif re.match('Zoo', TYPE):                CMD='zoo xqp'
elif re.match('ARC', TYPE):                CMD='arc pn'
elif re.match('LHa', TYPE):                CMD='lha p'
elif re.match('RAR', TYPE):                CMD='unrar p'
elif re.match('RPM', TYPE):                CMD='rpm -qpil'
#elif re.match('ARJ', TYPE):          unset CMD
elif re.match('ELF', TYPE):                CMD='strings'
elif re.match('Linux/i386', TYPE):         CMD='strings'
elif re.match('MS-DOS\ executable', TYPE): CMD='strings'
elif re.match('MS-Windows', TYPE):         CMD='strings'
elif re.match('Win95\ executable', TYPE):  CMD='strings'
elif re.match('bzip2\ compressed', TYPE):  CMD='bunzip2 -d -c'
elif re.match('bzip\ compressed', TYPE):   CMD='bunzip -d -c'
elif re.search(".bz$", sys.argv[1]):       CMD='bunzip -d -c'
elif re.search(".bz2$", sys.argv[1]):      CMD='bunzip2 -d -c'
else:                                      CMD=None

if CMD:
    print os.popen("%s %s 2> /dev/null" % ( CMD, FILE )).read()
-----------------------------------

Note: no logic was corrected in this simple (7.2) re-write...

HTH,
Pierre

> -Al
> 
> On Friday 22 June 2001 13:51, Pierre Fortin wrote:
> > Hi,
> >
> > Before I go digging into the sources, does anyone know the logic behind
> > "less" being impacted by the contents of .bashrc...?
> >
> > If I add 'echo "foobar"' to my .bashrc, any attempt to "less <file>" gives
> > only "foobar" as output instead of the expected contents of <file>.
> >
> > The env. vars are:
> > $ for e in ${!LESS*}; do echo $e ${!e};done
> > LESS -MM
> > LESSKEY /etc/.less                 #doesn't exist
> > LESSOPEN |/usr/bin/lesspipe.sh %s  #nothing weird here
> >
> > I've strace'd it and see this line:
> >   pipe([5, 6])                            = 0
> > (the numbers are not always 5 & 6) which is probably from the LESSOPEN
> > pipe...
> >
> > I don't see less opening .bashrc or invoking it; but less somehow gets
> > output from .bashrc...  What I can't determine yet is whether this "output"
> > is from ..bashrc executing anew when less is run (most likely -- see
> > below), or from a stale buffer somewhere...  I just can't imagine a
> > scenario where less needs to either access .bashrc or get data from a
> > non-user-specified pipe...   could this be a potential security hole...?
> >
> > The problem is even more confusing if I add some code to .bashrc; it gets
> > executed when I invoke less, instead of displaying the requested file...
> > this would seem to indicate .bashrc is executed when less is invoked...
> >
> > This happens on both my LM7.2 machines; but not on the 8.0 one, though the
> > latter has the same env. vars and the same pipe in strace output... but,
> > the default .bashrc is different...
> >
> > Puzzling.
> >
> > Pierre

-- 
Support Linux development:  http://www.linux-mandrake.com/donations/
Last reboot reason:  06/22/01: added 512M memory

Reply via email to