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
On 30 Sep 2000, Perl6 RFC Librarian wrote:
>The syntax should be something like the current C
>directives, possibly something like:
> use sandbox 'fs' (. => ALLOW_SUBDIRS | ALLOW_READ |
> ALLOW_READ | ALLOW_CLOBBER);
That should read
| use sandbox 'fs' (. => ALLOW_S
In RFC353, I totally missed some of the problems with implementation. In
fact, what may actually be needed (with shared library code, in
particular) is that using the sandbox system causes a fork, and then the
child is ptrace()d by the parent perl process. This of course traps every
possible syste
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
A Sandboxing mechanism for Perl 6
=head1 VERSION
Maintainer: Matthew Byng-Maddick <[EMAIL PROTECTED]>
Date: 30 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 353
Version: 1
Status: Deve
16 matches
Mail list logo
