5

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

   -delete
      ... 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?

NReilingh
  • 5,737
  • 3
  • 27
  • 52

1 Answers1

4

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.

jjlin
  • 15,462
  • 4
  • 51
  • 51
  • 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 07: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 07: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 07: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 07:52