Re: Quasi-(un)deletion question
On Sun, Feb 15, 2004 at 09:20:55AM -0500, Tim Otten wrote: The other day, I did something really stupid. I started a download with BitTorrent, and, half-way through, deleted the file it was downloading. The file still existed because the torrent client had it open. I could use 'lsof' to get an inode number -- but I needed some way to get access to that node without having an entry in the file tree. [...] Is it possible to access the file using a utility or small C program? Would you have to write code for the kernel? This probably won't be of much use to you: There are basically 2 approaches: (1) debugfs(8) or equivalent (2) injecting code in the bittorrent program, which would do a ``cat deleted_file recovered_file'' equivalent. gdb(1) might be of some limited help here. Using a known security vulnerability would be an extremely cute approach ;-) As I think about it, (2) isn't as silly as it seemed to be at the first glance: Suppose the bittorrent calls an external program (/bin/foo, or, better /usr/lib/bittorrent/bar), or a function of a library that can be replaced during the program runs. The file descriptors are inherited when forking. So all you'd have to do is to add a fork at the beginning of the callee code. The parent would continue normally, and the child would copy the deleted_file (on the inherited descriptor) to a recovered_file. HTH. -- Jan Minar Please don't CC me, I'm subscribed. x 9 pgp0.pgp Description: PGP signature
Re: Quasi-(un)deletion question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Feb 15, 2004 at 09:20:55AM -0500, Tim Otten wrote: The other day, I did something really stupid. I started a download with BitTorrent, and, half-way through, deleted the file it was downloading. Is it possible to access the file using a utility or small C program? Would you have to write code for the kernel? You're boned. Word to the wise: Think twice, delete once. - -- .''`. Paul Johnson [EMAIL PROTECTED] : :' : `. `'` proud Debian admin and user `- Debian - when you have better things to do than fix a system -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAL71lUzgNqloQMwcRAgdWAJ98EWfwGv0Php51MwSA4aIFpajYTgCfXnxm TGizErW5QIENwkrLoLoEJRo= =ejNi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quasi-(un)deletion question
Tim Otten [EMAIL PROTECTED] writes: The other day, I did something really stupid. I started a download with BitTorrent, and, half-way through, deleted the file it was downloading. The file still existed because the torrent client had it open. I could use 'lsof' to get an inode number -- but I needed some way to get access to that node without having an entry in the file tree. I looked in a bunch of obvious places -- /proc/nnn/fd, man pages and source for mknod, ln, and libc's link(). But it seems that all the work relating to actual inodes is done in kernel space -- where I have no experience. /proc/PID/fd seems to work just fine; see transcript below. Is it possible to access the file using a utility or small C program? Would you have to write code for the kernel? [EMAIL PROTECTED]:~ echo This is a test. t.txt [EMAIL PROTECTED]:~ tail -f t.txt /dev/null# keep file open [1] 1334 [EMAIL PROTECTED]:~ rm t.txt [EMAIL PROTECTED]:~ cat t.txt cat: t.txt: No such file or directory [EMAIL PROTECTED]:~ cd /proc/1334/fd [EMAIL PROTECTED]:/proc/1334/fd ls -l total 0 lrwx-- 1 martin users 64 Feb 15 19:45 0 - /dev/pts/2 l-wx-- 1 martin users 64 Feb 15 19:45 1 - /dev/null lrwx-- 1 martin users 64 Feb 15 19:45 2 - /dev/pts/2 lr-x-- 1 martin users 64 Feb 15 19:45 3 - /home/martin/t.txt (deleted) [EMAIL PROTECTED]:/proc/1334/fd cat 3 This is a test. [EMAIL PROTECTED]:/proc/1334/fd cat 3 ~/recovered [EMAIL PROTECTED]:/proc/1334/fd cd [EMAIL PROTECTED]:~ kill 1334 [1]+ Terminated tail -f t.txt /dev/null [EMAIL PROTECTED]:~ cat recovered This is a test. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quasi-(un)deletion question
On Sun, Feb 15, 2004 at 10:41:41AM -0800, Paul Johnson wrote: On Sun, Feb 15, 2004 at 09:20:55AM -0500, Tim Otten wrote: The other day, I did something really stupid. I started a download with BitTorrent, and, half-way through, deleted the file it was downloading. Is it possible to access the file using a utility or small C program? Would you have to write code for the kernel? You're boned. Care to back that up? As long as a running process has the file open, it's a well-known Unix semantic that the data's still on the filesystem: cp from /proc/pid/fd/foo will recover whatever's currently in the file, for instance. The tricky bit is getting a copy just as the download finishes, which implies either recreating a link to the deleted inode or perhaps some evil ptrace(2) hackery (PTRACE_SYSCALL, check for close() and if so copy contents of fd, otherwise PTRACE_SYSCALL again). I have a nagging feeling that there ought to be a better way, but the only other way I can think of to recreate a link to a deleted inode would involve a kernel module. A flink() syscall has been proposed, but designing and implementing it correctly would be complicated. You can easily create security holes if you get it slightly wrong. Word to the wise: Think twice, delete once. This, of course, is always good advice. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quasi-(un)deletion question
Incoming from Martin Dickopp: Tim Otten [EMAIL PROTECTED] writes: The other day, I did something really stupid. I started a download with BitTorrent, and, half-way through, deleted the file it was downloading. [EMAIL PROTECTED]:~ echo This is a test. t.txt [EMAIL PROTECTED]:~ tail -f t.txt /dev/null# keep file open [1] 1334 [snip good example] However, that's just standard *nix filesystem behaviour. You can rm 'til the cows come home, but as long as one symlink to the data remains, the data remains as well. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quasi-(un)deletion question
(1) debugfs(8) or equivalent Ah! debugfs looks perfect. I probably couldn't have added an entry for the file (because the filesystem was mounted, and the man page doesn't say whether it's safe to edit a live filesystem), but the 'dump' command worked fine in a test that I just did. (2) injecting code in the bittorrent program, which would do a `cat deleted_file recovered_file'' equivalent. This is very clever, but not as easy. :) Thank you muchly. - Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quasi-(un)deletion question
On Sun, Feb 15, 2004 at 12:11:18PM -0700, s. keeling wrote: However, that's just standard *nix filesystem behaviour. You can rm 'til the cows come home, but as long as one symlink to the data remains, the data remains as well. Hard link not symlink :) Bijan -- Bijan Soleymani [EMAIL PROTECTED] http://www.crasseux.com signature.asc Description: Digital signature
Re: Quasi-(un)deletion question
On Sun, Feb 15, 2004 at 02:03:06PM -0500, Tim Otten wrote: file (because the filesystem was mounted, and the man page doesn't say whether it's safe to edit a live filesystem), but the 'dump' command worked fine in a test that I just did. It's not. You did it the most right way. -- Jan Minar Please don't CC me, I'm subscribed. x 9 pgp0.pgp Description: PGP signature
Re: Quasi-(un)deletion question
/proc/PID/fd seems to work just fine; see transcript below. OMG. That does work. I didn't try it because the file looks like a symlink in 'ls' -- a similar process with symlinks on a normal filesystem will produce different results: [EMAIL PROTECTED]:/tmp$ echo This is a test t.txt [EMAIL PROTECTED]:/tmp$ tail -f t.txt /dev/null [1] 15538 [EMAIL PROTECTED]:/tmp$ ln -s t.txt t.txt-symlink [EMAIL PROTECTED]:/tmp$ rm t.txt [EMAIL PROTECTED]:/tmp$ cat t.txt-symlink cat: t.txt-symlink: No such file or directory So the proc filesystem somehow provides hardlink semantics with a symlink facade? Thanks. - Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quasi-(un)deletion question
Tim Otten [EMAIL PROTECTED] writes: /proc/PID/fd seems to work just fine; see transcript below. OMG. That does work. I didn't try it because the file looks like a symlink in 'ls' -- a similar process with symlinks on a normal filesystem will produce different results: Yes, /proc is quite different from other filesystems in many ways. :) [EMAIL PROTECTED]:/tmp$ echo This is a test t.txt [EMAIL PROTECTED]:/tmp$ tail -f t.txt /dev/null [1] 15538 [EMAIL PROTECTED]:/tmp$ ln -s t.txt t.txt-symlink [EMAIL PROTECTED]:/tmp$ rm t.txt [EMAIL PROTECTED]:/tmp$ cat t.txt-symlink cat: t.txt-symlink: No such file or directory So the proc filesystem somehow provides hardlink semantics with a symlink facade? The behavior is similar to hardlinks, but it's not really a hardlink, since hardlinks cannot work between different filesystems. A hardlink in the strict sense means that two or more directory entries refer to the same inode. That's not what's happening here. When the kernel is asked what type of file it is (as 'ls' does), it claims that it is a symlink. But when the kernel is asked for the content of the file (as 'cat' does), it returns the content of the open file on another filesystem. These two system-calls are really independent of each other, so the kernel can do that. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
