At 07:43 AM 5/8/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: We'd want an alternative opcode running loop for all this, and it could
>: easily enough check times, as could special opcodes. Long-running codes
>: could also check at reasonable breakpoints. (Still in trouble with C
>: exten
Dan Sugalski writes:
: We'd want an alternative opcode running loop for all this, and it could
: easily enough check times, as could special opcodes. Long-running codes
: could also check at reasonable breakpoints. (Still in trouble with C
: extensions, but that's pretty much a guarantee)
It's
At 02:46 PM 5/4/2001 +0100, Michael G Schwern wrote:
>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 h
On Fri, May 04, 2001 at 09:03:05AM -0500, Jarkko Hietaniemi wrote:
> > Memory limits we should be able to do, assuming Perl 6 continues to
> > have its own malloc.
>
> Well... Perl doesn't use it's own malloc *that* widely.
Who knows what Perl 6 will do internally, but we'll probably have some
s
> Memory limits we should be able to do, assuming Perl 6 continues to
> have its own malloc.
Well... Perl doesn't use it's own malloc *that* widely. E.g. Linux
doesn't, since at least 5.005_03. FreeBSD doesn't. OpenBSD doesn't.
Darwin doesn't. AIX doesn't. IRIX doesn't. Starting from 5.8.0
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
At 12:03 PM 5/4/2001 +0100, Michael G Schwern wrote:
>Sure, Unix has ulimits, ipchains, quotas,
>etc... but what about the DumbOS's and the AncientOS's?
You'll want to be careful of the epithets there. For this stuff the world
is really divided into single-user and multi-user OSes. Unix ranks do
On Thu, May 03, 2001 at 03:53:53PM -0500, David L. Nicol wrote:
> the larger question remains, is sandboxing something a language
> should support at all, or is it best left to the OS to provide
> a solid chroot facility?
CPANTS will have to try and clunk a sandbox together and
> The biggest problem I have with sandboxing is that to do it right is
> apparently difficult, judging by the number of people that get it wrong. We
> need to rope in a security expert, I think, for the design.
>
> I don't suppose we have one in the house somewhere?
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> At 05:22 PM 5/3/2001 -0400, John Porter wrote:
> >David L. Nicol wrote:
> > > is sandboxing something a language should support
> > > at all, or is it best left to the OS to provide
> > > a solid chroot fac
At 05:22 PM 5/3/2001 -0400, John Porter wrote:
>David L. Nicol wrote:
> > is sandboxing something a language
> > should support at all, or is it best left to the OS to provide
> > a solid chroot facility?
>
>IMHO this is one of those things that should be kept firmly
&g
David L. Nicol wrote:
> In all the discussion of customizing the parser, let us not
> forget that we also need to be able to limit the parser.
O.k., but what you say below isn't about limiting the parser,
it's about limiting the VM.
> is sandboxing something a language
>
In all the discussion of customizing the parser, let us not
forget that we also need to be able to limit the parser. The
"Penguin" module offers one interface for doing that. But
the larger question remains, is sandboxing something a language
should support at all, or is it best l
13 matches
Mail list logo
