> The script rmbug (attached) will demonstrate how "rm -rf" segfaults with > deep directories.
Thanks for your report. That has been just recently fixed in the latest of the test releases. But heed Jim's announcement warnings about it. Jim writes: > This is a pretty big delta. > You might even call it dangerous, since I've rewritten rm(!). > The goal of the rewrite was to make it so rm can now remove > hierarchies of effectively arbitrary depth. Before, rm would > dump core when trying to remove a hierarchy of depth around > 22000 or greater. Of course, it retains the relatively new > code to prevent a local attack on a privileged process removing > a hierarchy owned by the attacker. > > If any of you have time, please try rm with various combinations of its > options, to see if I've missed anything glaringly obvious -- or anything > subtle :-) In particular, -i, since I haven't tested that as much as > the others. ftp://alpha.gnu.org/gnu/fetish/fileutils-4.1.9.tar.gz (2.4 MB) ftp://alpha.gnu.org/gnu/fetish/fileutils-4.1.9.tar.bz2 (1.6 MB) http://fetish.sf.net/fileutils-4.1.9.tar.gz (2.4 MB) http://fetish.sf.net/fileutils-4.1.9.tar.bz2 (1.6 MB) Also, for future postings I recommend that small scripts and other small text files such as the one you included be posted as plain text instead of base64 encoded attachements. You will see what I am talking about when you look at your own posting here. Encoding it prevents casual browsing and prevents being able to search it. http://mail.gnu.org/pipermail/bug-fileutils/2002-July/002680.html Bob > I believe this is because it runs out of stack when the > recursive routines are called enough times. With the default (on my > system, anyway) of 8192k stack, about 13500 levels deep is necessary to > make rm segfault. On some filesystems, like reiserfs, it takes only a few > seconds to create a hierarchy this deep. > > This could be abused maliciously, for instance to make /tmp run full when > scripts to delete old files don't work, which in turn could cause all > sorts of weird behaviour. I guess this might qualify as a local DoS. The > solution is to rewrite the code to delete the directories using a > while-loop instead of recursion, something like the perl script rm-rf > (attached). Use with care, it has not been tested much. > > regards, > Ketil Froyn _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
