Well, IIUC, chroot operates at the process level. I don't think that chrooting a lightweight haskell thread using FFI can ever make sense. I see two cases here: 1) You actually want to chroot lightweight threads. In this case, write a little ChRoot wrapper monad around IO that supports chrooted implementations of all of the operations you need. Depending on how much you need and how elegant it needs to be it might be a lot of work. 2) You want to launch non-haskell processes inside the chroot you just created. In this case, use forkProcess/fchroot/executeFile or even add chroot to the command line invocation. If you want to do both, do (2) inside (1). It would help to know on a broader level what your goal is. --Lane On Sat, 27 Dec 2008, Jeremy Shaw wrote:
Hello,
I am working on an application where I would like to chroot a thread, but I am not seeing a way to do it.
I already have code which can run an IO action inside a chroot. The type signature is:
fchroot :: FilePath -> IO a -> IO a
The first argument is the new root, the second argument is the action to run with that root.
You can see the implementation here if you are curious:
http://src.seereason.com/build-env/Chroot.hs
The problem with that function is that chroot affects the root of the whole process. In a single-threaded program this is (possibly) ok, because the original root is restored after the IO action completes (though with unsafeInterleaveIO, perhaps bad stuff will happen). In a multithreaded program it can be disasterous.
As far as I know, the only solution would be to implement a function like fchroot which looks more like:
pchroot :: FilePath -> IO () -> IO ExitCode
Here the IO action would be forked off and run in a whole new process so that changing its root does not affect other 'threads'. Of course, you also can't use any of the nifty Haskell intra-thread communication stuff. Basically you can pass some values in and get back an exit code.
However, I am not even sure how to implement a useful version of pchroot. In theory, I can just use forkProcess, but, the Giant Warning for forkProcess indicates that this will not be very useful in practice:
forkProcess comes with a giant warning: since any other running threads are not copied into the child process, it's easy to go wrong: e.g. by accessing some shared resource that was held by another thread in the parent. Another example is the I/O manager thread: since the I/O manager isn't running in the child, attempting to do any Handle-based I/O will deadlock.
Anyone have an ideas ?
Thanks! - jeremy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe