On Fri, May 04, 2001 at 09:20:13AM -0400, Dan Sugalski wrote:
> Building a good sandbox with resource limits on a VMS system is trivial. I
> expect it may even be easier with IBM's big iron OSes.
I'm sure it is. I'm just worried about having lots of:
if( $^O =~ /VMS/ ) {
do some really scarey (to a Unix user) VMS hacks
}
elsif( $^O =~ /Big Iron/ ) {
do some different really scarey hacks
}
etc...
Obviously this will have to be done at some point, but I'd rather it
was encapsulated somewhere. Either inside Perl or in some core
sandbox/Safe module.
> It's less trivial with Unix, but not bad. Beats me on WindowsNT,
> though I'd bet it's up to the task.
>
> The single-user OSes are more problematic. I don't know that MacOS (before
> OS X) provides the info we need but as of System 7.x it didn't. Nor Win9x,
> or AmigaOS. (Though for those we can still track memory usage)
I'd prefer that when we think about the cross-platformness of Perl 6
we keep these troublesome OS's in mind as far as considering what Perl
should leave to itself and what it should leave for the OS to decide.
> Luckily the security sandbox features are all implementable from
> within perl. It's the resource limitation ones that are trickier,
> especially CPU time.
Memory limits we should be able to do, assuming Perl 6 continues to
have its own malloc.
CPU usage is a problem... we could provide two similar, but easier to
implement, features. Throttling (by sticking a tiny little sleep
between each opcode) and limited running (ie. kill yourself if you run
longer than X seconds). The latter we might be able to pull of
externally using SIGALRM, but not all systems have that.
Also things like limiting the number of open filehandles and sockets and
limiting network usage could be done inside perl.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
And Solaris must be destroyed.
-- Peter Miller
