From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] mv vs cp In-Reply-To: <87pu7wuxof.fsf@becket.becket.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 10 Oct 2001 06:29:11 -0400 Topicbox-Message-UUID: 04b970f4-eaca-11e9-9e20-41e7f4b1d025 On Wed, 10 Oct 2001, Thomas Bushnell, BSG wrote: > viro@math.psu.edu (Alexander Viro) writes: > > > BTW, while we are at it, check what does GNU find(1) (which is the > > default on Hurd, IIRC) do when somebody moves a directory while > > find is walking through its subdirectories. And think about the > > implications. What was that about correctness and completeness, again? > > find does not necessarily traverse every file on an active partition. > > But that has nothing to do with the moving of directories? The same > thing happens with the moving of single files too. GNU find traverses the tree with chdir() into subdirectories and _blind_ chdir("..") to go back. Cwd follows directory when you do rename(2). It does no such thing if you do mkdir() + recursive copy + recursive remove + rmdir(). See the problem now? "Find something under /tmp and do something with all such objects" can be subverted into "find something under / and do something with all such objects" by attacker that has access only to subdirectories of /tmp. And no, it's not only GNU. Solaris find(1) has the same lovely property (at least had it not too long ago - I hadn't checked the recent versions). And it's not only find(1) - other tree-walkers are often vulnerable to the same kind of crap. I don't think that security implications really need to be explained. Before you start saying that shared /tmp or all-mighty root are bad ideas, think for a minute and see how the scenario can be modified for situations other than one described above. Notice that "generate pathnames and don't bother with chdir() at all" is also not an answer. E.g. Plan 9 rm(1) would become a glaring security hole if ported on any recent UNIX. Symlink attacks would make it very interesting... Something like dup, walk, clunk, stat and remove exported to userland would allow to do such stuff more or less elegantly, but without that you need fchdir() to avoid symlink attacks. Anyway, the point is that cross-directory rename(2) leads to userland bugs that are really nasty and, as experience shows, not obvious for a lot of people. Actually you've just demonstrated that. It's not about kernel simplicity; userland code becomes much more complicated to be able to cope with effects of having cross-directory rename(2) around.