In article <003b01bfb169$72cbbb20$0100a8c0@kodachi>,
Richard Nienhuis <nienhuir@concentric.net> wrote:
> I don't think the kernel already has this, what I want is a way to
> redirect where processes can open files.
You can hack something up, but I'm not aware of any clean solution.
Use ptrace() to monitor all open(), creat(), rename(), etc., syscalls
performed by the process of interest. If I remember correctly, it is
possible to modify syscall arguments using ptrace(). You'll incur a
pretty large performance overhead, but maybe that's ok for your purposes.
This is roughly what I do in Janus, a secure "jail" for untrusted code
(like chroot, but better); see http://www.cs.berkeley.edu/~daw/janus/.
But the much larger issue is that syscalls are at the wrong level of
abstraction. Your code will have to understand all the syscalls that
can touch files (there are quite a few), canonicalize path names
(relative paths, "..", and so on), deal with symlinks and hardlinks,
and in general duplicate an awful lot of pathname handling code that's
already in place in the kernel. That's ugly, and error-prone.
It would be far nicer if we had a convenient interface for interposing
at the inode layer, rather than at the syscall level. This would be
great for the security tool I mentioned above, and probably much better
for your purposes, too. But I'm not aware of any existing solution.
Do linux-kernel readers have any ideas on how one might build a
general inode-level filesystem-interposition mechanism for Linux?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:12 EST