Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I think what I'm talking about is this part of the manpage, which is just barely too indecipherable for me:

      ... It will not attempt to delete a filename with a ``/'' character in its
      pathname relative to ``.'' for security reasons...

Specifically, what I'm trying to do is $ find . -name '.svn' -type d -delete. I realize I can use -exec for this instead, but find appears to work without issue for other names, including deep in directories (that obviously contain many / characters in their pathnames).

Perhaps it's ignoring dotfiles instead and the documentation is wrong?

share|improve this question

The "security reason" is that between the time that find is enumerating the files and deleting them, it may be possible for an attacker to modify one component of a file's path such that it becomes a symlink to an unexpected directory, resulting in your deleting a file of the same name from an unexpected directory. For example, you could end up deleting /etc/passwd rather than /tmp/foo/passwd if the attacker can change foo to be a symlink pointing to /etc.

Section 9.1.5 ("A more secure version of -exec") of the GNU find documentation discusses this problem in more detail.

share|improve this answer
It's the relative to . part that has me confused. I don't see why I can remove a file like asdf/somefile.txt using -delete relative to my working directory, but not asdf/.svn – NReilingh Feb 17 '12 at 7:12
The . is not talking about dot-files, like .svn; it's talking about the Unix notation for "current directory" or "working directory", which is .. In this context, I don't see a security reason to distinguish between dot-files and other files. So are you saying that your find command doesn't work on .svn but does work on other files? The only reason I can think of is -delete doesn't really work on non-empty directories, AFAIK. – jjlin Feb 17 '12 at 7:28
Indeed--that's what's confusing about this. I understand that . is the working directory, but I don't understand how the manpage claims it is designed to fail on ALL subdirectories of the relative working directory, when that is clearly not the case. – NReilingh Feb 17 '12 at 7:46
Ah. Then it may very well be the case that the manpage is just out of date, and they have since implemented a more secure -delete and removed that limitation. I don't have access to any OS X machines, so I can't say for sure there. – jjlin Feb 17 '12 at 7:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .