Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [Bug] Strange Globing Behaviour when used with sudo

On Fri, Jun 01, 2018 at 11:08:30PM +0900, Jun T. wrote:
> > 2018/06/01 03:15, Daniel Tameling <tamelingdaniel@xxxxxxxxx> wrote:
> > 
> > As s is NULL and buf is in the example ./file/, statfullpath adds to
> > buf a . so that it's "./file/.".
> (snip)
> >  So one possibility to fix this is to
> > call stat before adding the . to ./file/, and the return non-zero if
> > it is not a directory.
> Yes, but users can add '.' by themselves, for example
> sudo zsh -c 'echo */.'. And of course you can not just
> "return !S_ISDIR(st->st_mode)", and st may be NULL.
> I've also fond that stat("file/..") is similarly broken.
> In the patch below, I enclosed everything within "#ifdef __APPLE__"
> to minimize the side effects. It is difficult to detect the bug
> by configure since it requires sudo.

Your patch works, but it didn't solve everything. So while
$ sudo zsh -c 'echo */..
results in "no matches found", but already adding a slash and you get
again output:
$ sudo zsh -c 'echo */../
This is not so easy to fix because you can continue the path after .. :
$ sudo zsh -c 'echo */../.././directory/'
So fixing this would probably mean, you need to iterate over the path,
and whenever encountering "." or ".." checking whether everything
before is really a directory.

But note that fixing the problem would also lead to a behavior that
some might find counter-intuitive:
$ sudo zsh -c 'ls file/..'
$ sudo zsh -c 'ls */..'
zsh:1: no matches found: */..

I noticed bash manages to trigger the ls error message when zsh
outputs "no matches found" 
$ bash -c 'ls */..'
ls: cannot access '*/..': No such file or directory


Messages sorted by: Reverse Date, Date, Thread, Author