> The issue is more about whether he wants to limit *all* file system
> access or just limiting to certain areas. For the former,
> I would set up a chroot jail and run R from within; for the latter,
> I would probably do something with LD_LIBRARY_PRELOAD to override
> all the file system accessing functions in libc directly, really.
> That would fix the problem with system(rm) and some such, I think,
> because if your entire R process and any sub-process R launches has no
> access to the genuine libc fwrite/fread/etc functions you cannot do
> any demage, right?
> Both are tricky and take time to do (the chroot jail a bit easier,
> actually...), but quite do-able.
a sneaky trick:
for each compute session, automate setting up a zone ("solaris
containers") on a solaris 10+ box. if you have a
preinstalled/preconfigured zone template, snapshotted with zfs, you can
roll out a new compute zone in literally seconds. you can quota it, limit
the amount of CPU it gets, etc. really not very difficult at all to set
up. sun's tools are *great* for this nowadays.
this is substantially safer than chroot() or LD_PRELOAD tricks, and lets
you do this stuff without having to invent the wheel.
it also reduces overhead to the point where you really *can* set up a
naked compute (well, with R in it...) environment for every compute
session getting instantiated. in way, way, way less time than it takes
for the computations to actually run.
if someone does system(rm) in a container... who cares? they just trashed
their own session, and nothing else. just blow the trashed ones away
periodically.
--e
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
