bugfindutils - Bugs: bug #17782, unwanted prefix "./"...

 
 

bug #17782: unwanted prefix "./" before arguments when using -execdir with find

Submitter:  Andreas Metzler <ametzler>
Submitted:  Sun 17 Sep 2006 10:51:44 AM UTC
   
 
Category:  find Severity:  4 - Important
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  WANG Yunfeng Open/Closed:  Closed
Release:  4.2.28 Fixed Release:  4.2.29
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 08 Nov 2006 07:12:16 AM UTC, comment #7: 

This is fixed in CVS for both 4.2.x and 4.3.x.

James Youngman <jay>
Group administrator
Wed 08 Nov 2006 07:11:51 AM UTC, comment #6: 

This problem is fixed in the CVS code for findutils.
To resolve your problem, you could either wait for the
next official release of findutils, or check out a copy
of the code from the CVS repository for findutils.

James Youngman <jay>
Group administrator
Thu 19 Oct 2006 06:03:17 PM UTC, comment #5: 

Well, if that is not the outcome you expected, I should fix the documentation.  I won't be making the change you suggest as that would break the secure handling of files with names like "-i".

James Youngman <jay>
Group administrator
Thu 19 Oct 2006 05:26:51 PM UTC, comment #4: 

WANG Yunfeng in http://bugs.debian.org/385896

> Follow-up Comment #1:
>
> Prefixing the expansion of {} with ./ is a security feature.  I'm not
> planning to remove it.
>
> However, as Andreas points out the actual bug here is that arguments
> containing {} are prefixed with ./ at the start of the argument, even if the
> {} is not at the start of the argument.   Example:
>
>
> $ find baz -execdir echo 'foo {}' \;
> ./foo baz

Here we need a little more consideration. Thinking about this situation:

Under current directory exists some file whose name looks like `bashrc',
and I want to rename it to `.bashrc', so I would probably run:

$ find . -name "[^.]*rc" -execdir mv {} .{} \;

According to patch file sv-bug-17782.patch, this will result in a command
like `mv ./bashrc ../bashrc', which is definitely not expected.

As a compromise, I suggest to provide an option, say `-suppress_prefix',
to disable this feature for those who really don't need it with -execdir,
while enable it by default for the general purpose invokation.

Andreas Metzler <ametzler>
Mon 16 Oct 2006 09:47:44 AM UTC, comment #3: 

The attached patch (against 4.2.x CVS) should fix the problem.

James Youngman <jay>
Group administrator
Sun 15 Oct 2006 01:42:48 PM UTC, comment #2: 

This bug affects all versions of versions of findutils which support -execdir:

findutils-4.2.12
findutils-4.2.13
findutils-4.2.14
findutils-4.2.15
findutils-4.2.16
findutils-4.2.17
findutils-4.2.18
findutils-4.2.19
findutils-4.2.20
findutils-4.2.21
findutils-4.2.22
findutils-4.2.23
findutils-4.2.24
findutils-4.2.25
findutils-4.2.26
findutils-4.2.27
findutils-4.2.28
findutils-4.3.0
findutils-4.3.1

Versions of findutils prior to 4.2.12 don't support -execdir and are thus not affected.

James Youngman <jay>
Group administrator
Sun 15 Oct 2006 12:11:12 PM UTC, comment #1: 

Prefixing the expansion of {} with ./ is a security feature.  I'm not planning to remove it.

However, as Andreas points out the actual bug here is that arguments containing {} are prefixed with ./ at the start of the argument, even if the {} is not at the start of the argument.   Example:


$ find baz -execdir echo 'foo {}' \;
./foo baz

James Youngman <jay>
Group administrator
Sun 17 Sep 2006 10:51:44 AM UTC, original submission:  

This http://bugs.debian.org/385896 reported by WANG Yunfeng.

Short version
Bug:
ametzler@argenau:/tmp/testingfind$ find -type f -execdir echo sh -c 'file -b {} | true' \;
sh -c ./file -b d | true
Expected output
sh -c file -b ./d | true

Complete original bugreport follows:
---------------------------------------
When action "-execdir" was used with find, a string "./" was prepended
to any argument containing replace pattern "{}", leading to this error:

$ find -type f ! -name "*.gz" -execdir sh -c \

> 'file -b {} | grep -q "gzip compressed data" && mv {} {}.gz' \;

sh: ./file: No such file or directory

I've gone through codes related with this prefixing behavior in the
source code of findutils, and found these relevant lines:

line 509 in find/pred.c :
   const char *prefix = (state.rel_pathname[0] == '/') ? NULL : "./";
lines 278+ in lib/buildcmd.c :
      if (prefix)
        {
          strcpy (state->argbuf + state->cmd_argv_chars, prefix);
          state->cmd_argv_chars += pfxlen;
        }
...

In most cases such design was not a bad idea since {} was generally
placed alone, sometimes even quite good for dealing with unusual file
names like "-l". But if we want to do some complex operations as shown
above, this will turn to be a mess.

Possible resolution could be discarding this feature since those who
need prefix "./" can specify it explicitly at the beginning of argument;
or at least a switch to turn off this behavior should be provided.

Another possible bug concerning "-execdir" shown below:

$ pwd
/tmp
$ find / -maxdepth 1 -wholename / -execdir pwd \;
/tmp
$ find / -maxdepth 1 -wholename /boot -execdir pwd \;
/

Among these two find invocations, the latter conforms to the description
in find's manpage while the former does not. This inconsistency seems to
occur only when the matching filename was "/". I'm not sure if this is
another special handling or not.

ps: action "-okdir" works basically the same way as "-execdir".
-------------------------------

Andreas Metzler <ametzler>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #10981:  sv-bug-17782.patch added by jay (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Updated the item)
  • -email is unavailable- added by ametzler (original bug submitter)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2006-11-26 jay Item GroupNone Wrong result
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.2.29
    2006-11-08 jay StatusNone Fixed
    2006-10-16 jay Attached File- Added sv-bug-17782.patch, #10981
    2006-10-15 jay Severity3 - Normal 4 - Important
        Assigned toNone jay
    2006-09-17 ametzler Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code