Re: Security models in mzscheme ??

[John Casu <casuj@valinux.com>]

> On Tue, Dec 05, 2000 at 09:00:42AM -0700, Matthew Flatt wrote:
> > A little problem here: the `unit' form provides access to all of the
> > built-in the file primitives, even if they're not in the namespace.
> > 
> > This is the sort of problem that the new module system will solve.
> > 
> > Matthew
> 
> Good point.  I suppose that excluding unit and unit/sig from the namespace
> would work around this for now.
> 
> Paul
> 

Please forgive me if I'm being a little dense, but while your proposed solution
would surely work for the sandbox case, it's not clear to me that we would have
a solution for the more general case.

I'm guessing, but I think you'd want to be able to dynamically adjust your current
permissions/capabilities and have an interface like:

(with-user (get-user-id)
  (foo))

or more specifically :

(with-user (interactive-get-user-id user-port)
  (REPL user-port))


In addition, in a multiuser environment, you'd want to share namespaces between 
differently authorized REPL's, where you might have a global read-only namespace
for defining system level environment in addition to your local namespace.

In the more general case, I'm envisioning distributed groupware type applications 
using MrEd, where I'd want to take an input event and pass it to the eventspace/
event streams of each instance of my app.

The question, I think, then becomes at which point can you insert some notion of 
security into MzScheme ?  

Does one create some kind of uber-custodian which manages security, and then we
would have a coarse-grained view of security; or would one just create a new set
of parameterized functions like (make-secure-namespace permission), which would 
allow you a much more dynamic security model ?