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
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
