Re: security risk in source builtin?

[Dominik Vogt <zsh-users@xxxxxxxxxx>]

On Wed, Sep 17, 2003 at 07:48:53PM +0800, James Devenish wrote:
> In message <20030917110731.GA535@xxxxxx>
> on Wed, Sep 17, 2003 at 01:07:31PM +0200, Dominik Vogt wrote:
> > > >   $ source test
> > > >   /usr/bin/test:3: bad pattern: ^@^F^@(...
> [...]
> > To the casual user, it is not obvious why the $PATH should be
> > searched.  After all, scripts read with "source" or "." should
> > usually not be executable, so they do not belong into any
> > directory in the $PATH.
> [...]
> > At the very least, I
> > think "source" and "." should not attempt to read files in the
> > $PATH that are not executable.  Of course this is only my mersonal
> 
> As you mentioned, the . command is provided by the POSIX shell. I would
> expect that changing its behaviour would cause existing scripts to fail,
> as well as affecting portability. I think that it is bad to be scripting
> with ". test" if you desire the semantics of ". ./test" (in the case
> that you use "./test", $path will not be searched). You are right that
> it is a "trap" to fall into, but there is a definite difference between
> ". test" and ". ./test" and it is probably more important that authors
> code carefully (as always applies to coding).

Okay, this is what POSIX says for ".":

  If file does not contain a slash, the shell shall use the search
  path specified by PATH to find the directory containing file.
  Unlike normal command search, however, the file searched for by
  the dot utility need not be executable.

which is implemented correctly in zsh, but not in bash (who cares
;-) ) or pdksh.  I.e. zsh looks in the $PATH only while bash tries
. if $PATH fails.  "source" is not part of POSIX.  So it seems the
security problem is in the POSIX spec itself :-P

Ciao

Dominik ^_^  ^_^