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 I have no
illusion
> 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?
"Where have you gone, Malco
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 facility?
> >
> >IMHO this is one of those t
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
>in the front of our minds as
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
> should support at all,
12 matches
Mail list logo
