On Mon, Jul 18, 2016 at 12:13:30PM -0700, Peter Chen wrote: > Hi, > > I was wondering if I intercepted the system call such as read(). Hopefully not, since there is no race-free way of doing that. OTOH, rootkit writers usually do not give a damn... > Can > I get the file path of the file descriptor somehow from the kernel > process's internal data structures or some helper functions? For > example if I had previously opened a file "abcd.txt", and then called > read on it, I would like to get the filepath "abcd.txt" from the fd > for the read(). The literal path used for open? No. If nothing else, it might have been unlinked since then. Or renamed, for that matter. What's more, there is no exclusion between rename() and read(), so there's no promise that the name would remain valid after you obtain it. Using d_path() on &file->f_path would give you what you'd see in /proc/self/fd/<n> at the moment, for whatever it's worth. > Also aside, I was wondering if it was all possible to get the file > path of the executable of the process itself. So if I was running a > program such as "ping", when I intercept the system calls of the > program, I want to know the filepath of the ping program. Depends. If that's debugging (as in "I want that printk happen only when we hit that line from a syscall in my test binary, so that it wouldn't swamp the log during boot"), comparing current->comm with the known name would be the usual quick-and-dirty approach. If you are really playing with rootkits... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
