On Mon, 21 Jan 2002 22:20:53 EST, Brian Coyle <brianat_private> said: > Copies of the subject disk images were mounted (ro,loop,nodev,noexec) such > that the original filesystem structure was maintained. > > $CRACKED_BOX/home/ftp appears to be a chroot jail (can you confirm Lance?) > containing bin, etc, lib and pub directories. Navigating into bin, etc and > pub followed by an `ls -l` each works fine. > > However, in lib, `ls -l` and `stat *` both fail with a segfault. Omitting > the -l option for ls does list the files. debugfs (ls -l) has no problem > with the directory. I'm wondering if you managed to get a bad copy of the disk image, and there's a busticated inode belonging to some file in lib/. To test: 1) cd lib/ 2) /bin/ls (you say this works) 3) (bash/ksh) for i in `/bin/ls`; do echo $i; /bin/ls -l $i; done This will find if there's a specific file that's giving ls and company indigestion. Then go poke that file's inode (which you can get with 'ls -i broken.file') with debugfs and see if it's corrupted in some way. I'm wondering if the $CRACKED_BOX had a kernel module loaded that used a previously reserved bit in the inode as a "hide me please" flag, and a modified lsattr/chattr command to set the bit, and 'ls' and 'stat' both die when they see a non-zero in the reserved bit, but debugfs ignores it (since debugfs is *expecting to see broken inodes, and 'ls' is expecting to be handed correct ones). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
This archive was generated by hypermail 2b30 : Tue Jan 22 2002 - 11:10:13 PST