bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] find/pred.c: basename versus base_name.


From: James Youngman
Subject: Re: [patch] find/pred.c: basename versus base_name.
Date: Thu, 3 Feb 2005 23:23:26 +0000
User-agent: Mutt/1.3.28i

On Thu, Feb 03, 2005 at 11:29:25PM +0100, Bas van Gompel wrote:
> Op Thu, 3 Feb 2005 22:38:58 +0300 schreef Dmitry V. Levin
> in <address@hidden>:

> :  I expect (and my change makes) following behavior:
> :  /tmp
> :  /usr/bin
> :  /tmp
> :  /usr/bin
> :  <listing of /usr/bin directory without its contents>
> 
> So, your change makes -execdir behave identical to -exec?
> If that is the case, it is wrong. See:
> $ info '(find)Security Considerations for find'
> (especially the last paragraph of section 8.2.2.)

I have put in place (in CVS) a quick fix for the problem.  It makes
-execdir work the same as -exec when (state.curdepth==0).  The problem
is that the working directory at that point will still be the same as
it was when we started, as we have not recursed into any directories
yet.

If you have a good suggestion as to how this should be better solved,
please let me know.

One option is for process_top_path to change working directory to the
parent directory of the item to be processed (unless
(0==strcmp(pathname,"."))).  However, this is nontrivial to implement
correctly since pathname might be "../../../.." for example.  Also the
named argument might be a directory which is searchable by the current
user, while its parent might not.

James.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]