nkuipers wrote: > Pardon my ignorance, but what's the deal? Unless it comes authored, tested > and at least partially documented, like a CPAN module for example (other than > Safe.pm ;), why take the risk of exposing one's system to some script off the > Net? Saves time? Why reinvent the wheel? How much time is spent ratifying > the script, or getting set up to do so? Two days perhaps? ;) Arguably, if > you can't accomplish a task by tailoring some combination of CPAN stuff to > your needs, it's time to role your own solution. It's just my two cents, > unasked for, and probably laughable. Oh well.
language-provided sandboxing is useful for several (if not many) things: - applets; - MUD stuffs (exchanging behaviour/code objects between users); - OS-independent protection layer (there's no chroot in win32); - fine-grained protection; - sub-process (like per-thread or per-package, etc) protection (on the OS level, protection is process-wide); basically, sandboxing is nice, because you can practice the Principle of Least Authority (which is a Good Thing). who knows what bugs a piece of code can contain, or what evil input data can an unsuspecting code receive? putting code in a flexible sandbox can minimize the potential damages. however, as steve grazzini has graciously demonstrated to me, perl5 cannot do effective sandboxing at all. not even with the latest version of Safe.pm. there's nothing that can prevent a piece of perl code from overwriting any file (as far as the OS permits, of course). so i might as well forget the whole idea of sandboxing perl scripts. -- dave -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
