You're right, of course. I had the semantics for rmdir() mixed up with umount() momentarily. I have fixed the comments in my copy of the patch, but won't bother to distribute it unless something else changes, or somebody is feeling really picky about their comments... This doesn't affect the security of the patch, though; once we are inside the directory, if somebody rmdir()s it and makes another directory with the same name, that's not the directory we're in, and we won't be tricked into overwriting anything as root (although we will rmdir() the fake directory). I tested this, and the bind() simply fails, which is no big deal. This is on Linux 2.2.12, and it looks like BSD exhibits the same behavior. ------Scott. Olaf Seibert <rhialtoat_private> writes: > On Sat, 2 Oct 1999, Scott Gifford wrote: > > > + /* OK, now we know we're in the directory we created. Nobody can > > + * rmdir() this because we are in it. Nobody besides root can have > > + * made a symlink in here, because they wouldn't have permission. > > + * Lookin' good... > > + **/ > > Actually, a directory *can* be rmdir()ed when it some process' current > directory. You can try that with a couple of shells for instance. But > once the directory is not empty, it cannot be rmdir()ed anymore. Perhaps > you can use that fact to your advantage. > > On the other hand, if you're in an rmdir()ed directory, a chdir ("..") > or a rename("somename", "../somename") also don't work, and it looks > like even creation of new files or sockets will fail too, so this could > probably be used as a detection after the fact. > > (all this on NetBSD 1.3.3) > > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert - rhialtoat_private -- If one tells the truth, > \X/ .kun.nl -- one is, sooner or later, to be found out. (Oscar Wilde)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:36 PDT