Lisp and “access control”

Robert Strandh in his Gracle concept is thinking about how Lisp might naturally support a multi-user “environment.” I wanted to capture a few random thoughts I had while reading it. First, what exactly is the notion of access control? His “complex objects” all live in a single large address space, and have access masks, which might or might not allow the “current user” of the process to peek inside.

I suppose the idea is that processes must share, between each other, and between the process and the underlying privileged “kernel”, some opaque objects, which are distinct parts of the universe of the single address space, but inside which only certain processes are allowed to “peek.” Perhaps all of the possible interpretations of “peek” boil down to pointer or slot de-references, and the basic operation of pointer or slot de-reference is controlled by the OS environment in a similar way to which, say, Linux controls the virtual memory hardware to prevent read or write access (or even the capability to form addresses of?) areas of memory which belong to other processes or to the kernel.

What sort of objects are required, and how much introspection is allowed outside this barrier? Given an object by the kernel, a thread should be able to tell at least what type or class the object is an instance of. It might also be allowed to know what user owns it or what thread produced it (represented by other opaque objects.)

Some of these objects might require other operations which would be considered a core part of Lisp. Can CONS cells be protected? Can I be given lists, CONS other cells into them, so that the first few elements belong to me, but beyond a certain point, I’m not allowed to see the list structure? Or know that they are CONS cells, but not see the CAR? Can I get the length? Can I PRINT and READ back such objects?

Are the routines/generic functions that operate on these objects in some space immune from re-definition? Are functions themselves instances of these opaque objects? I.e., can I generate a closure that cannot be called except by myself, or by myself and the kernel, or by myself and other threads that pass some test?

How do threads authenticate themselves to each other?

Are objects read from external “sockets” put into a notional sandbox of low privilege? Are functions I compile marked with the privilege of my compiler? How are general resources such as consumption of the single-level store allocated per thread?


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: