[bug #20951] Very bad/unclear/confusing documentationing for a security note of find's -execdir option

[anonymous]

URL:
  <http://savannah.gnu.org/bugs/?20951>

                 Summary: Very bad/unclear/confusing documentationing for a
security note of find's -execdir option 
                 Project: findutils
            Submitted by: None
            Submitted on: Saturday 09/01/2007 at 11:55 UTC
                Category: documentation
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Hamidreza Mz
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.2.27
           Fixed Release: None

    _______________________________________________________

Details:

from `find' info manual:
If you use``-execdir', you must ensure that the current directory is not on
$PATH, because otherwise an attacker could make `find' run commands of their
choice simply by leaving a suitably-named file in the right directory. GNU
find will refuse to run if you use `-execdir' and the current directory is in
$PATH.


man:
If you use this option, you must ensure that your $PATH environment variable
does not reference the current directory; otherwise, an attacker can run any
commands they like by leaving an appropriately-named file in a directory in
which you will run -execdir.

Finally I searched the web to understand the meaning of these sentences.

I found this:
http://www.gnu.org/software/findutils/manual/html_node/find_html/Race-Conditions-with-_002dexec.html#Race-Conditions-with-_002dexec
that says:
The -execdir action refuses to do anything if the current directory is
included in the $PATH environment variable. This is necessary because -execdir
runs programs in the same directory in which it finds files – in general,
such a directory might be writable by untrusted users. For similar reasons,
-execdir does not allow {} to appear in the name of the command to be run.

but I couldnt understand their meaning! becuase I couldnt even find an
answering test case for it to ensure of the situation  that caused that
behavior and its mechanism... I tested it many times in many fashions and by
several presumptions...

an instance of my tests:
address@hidden ~]# echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin
address@hidden ~]# cd /bin
address@hidden bin]# find . -name cp -execdir pwd ';'
/bin
address@hidden bin]# 


eventually I started a topic for it in a GNU/Linux (with a BSD section too)
dedicated forum and requested help .
I am Persian and that forum too; but codes inserted are in english!!
You can see that almost short discussion here if you want:
http://www.technotux.org/html/index.php?name=PNphpBB2&file=viewtopic&p=96442#96442


thanks to my friends finally we recognize that what problem was what that
confuses we.
We recognize also that it is obviously a fault in documentations that would
probably confuse most of the people that read it.
problem was that documents didnt indicate clearly what was their meaning of
the current directory (read this: you must ensure that the current directory
is not on $PATH). there are several probable assumptions for this: directory
that find is revoked from there; cwd for commands executed by -execdir that is
the directory that `find' finds target file(s) there; and finally  much far
assumption (I think for many people) as my friends said/named the `dynamic
current directory' (dot! - .) that is reasonably weird to see in $PATH (at
least for persons like we that have not seen such a manner to this time).
when you say cwd, persons think of that we thought at first. this is the
most/vary expected assumption. does you understand? oh I am a little verbose!!
(at least my rivals say that ;D)

you could and now should address this fault in your documentations as soon as
possible. please!! :D
I think that`s very easy to fulfil!
even by adding three characters `(.)' somewhere appropriate; although more
explanation seems to be proper.

anyway the letter is ending :(
thanks for you all lovely free software mans (and women!).
we knows you! we thank you for all things you bring to our community and
humanity.
we utilize all of your produced tools and knowledge everyday.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?20951>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/