--- David Whipp <[EMAIL PROTECTED]> wrote: > Kv Org [mailto:[EMAIL PROTECTED]] wrote > > I believe Perl6 needs a facility to run > > "compartmented" code (object-oriented and > > module-loading) that is tagged as to its > permissions > > and "owner" ID. The goal would be to let such code > use > > harmful actions only by calling permitteed outside > > functions that implement permission checks before > > calling potentially harmful code. > > I'm not an expert in this area, but I think that a > capabilities based model is probably better than > compartments.
Capabilities are a more generalised term for what is done with OpCode masks in Perl5. Compartments introduce a very important new concept: they provide a way to specify specially restricted capabilities for a part of code inside a given program, giving essentially a chrooted namespace. Code inside a Safe compartment can't get at any data outside of the compartment unless it is given special premission. That means that a part of your program can run without any restrictions, while another part is heavily restricted. That only begins to make sense when you imagine that other part being written by another user, read into the running perl, evaled and then called at appropriate time. > The model would be that a program starts with a > set of capabilities; and then any code that it > calls (or thread that it starts) would inherit > these capabilies -- a function call (or thread > start) could explicity deny some capabilities to > the code that it calls; also, a function could > return additional capabilities to the caller. > > Capabilities could be stored as a hash in the %MY > pad. The capability to add stuff to that hash would, > of course, be highly restricted. > > A capability is probably just an object: any module > can > define any number of capabilities; but only it (not > its subclasses) has the right to create instances of > that capability (which it can then return to a > requesting caller). When a function later trys to > use a protected method, that method would check that > its C<caller> has an appropriate capability I am a bit unsure about specification details here. I suspect Parrot will somehow need to have access to data about what parts of Perl (or other) source generated the current bytecode to generate error messages. I suspect a similar mechanism could be used to store information about _ownership_ of a part of code and use that in the capability granting methods. Many things are unclear here since the only reference specification (for lack of any RFCs dealing with the problem) is OpCode.pm and Safe.pm combo, which has problems and is very perl5 specific. I think a perl (and a parrot) program should be able to assign an "user" identity to parts of code (similar but not directly mapped to unix user ids, of course) and then be able to do capability/security decisions based on that. In this way I might be able to insert code into a running system but have it run with restricted permissions so it could not mess with the running program, only process data it gets handled to its functions and return results. Such code should be able to load modules and call functions in other modules, but probably only through securtiy-enforcing proxies. LPC, the C-like scripting language of LP Muds, was the most interesting implementation I have been able to find. It needs to deal with the problem of a multi-user programming environment running under a single unix user ID and inside a single process. It solves the problem with an object-oriented structure and file-based user/group ID system. It uses "real user ID" inside the MUD system to keep track of things and an "effective user ID" to grand extra permissions. Objects of one user can only communicate with other users's objects via "root id" objects that implement permission checks etc, or, in some implementations, the objects can do security checks themselves since object data can only be handled through accessor (get-set) methods and all communication between two objects is thus limited to method calls and system calls that themselves call method calls on other objects. It is a simple and very efficient system that has been used in multi-user gaming environments for over 10 years. But while it fulfills most of the requests I mentioned it maps badly to the perl6 paradigm of byte-compiled platform without a well-defined code-file relationship and non-blackbox object implementation where there are no restrictions to changing variables or even function definitions in other namespaces. >From perl's point of view, restricted code parts should probably be put under a special namespace hierarchy with all the capability checking and granting hidden well away. A clear semanitcs for interaction with non-restricted and other restricted modules would need to be specified to enable such restricted code to call functions in other parts of code and, above all, use module libraries. Unfortunately, that is a nontrivial itch I can't scratch myself. Fortunatelly it is also a capability that would, in my opinion, much enhance perl's capabilities. Suggestions? __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
