[e-lang] More on "Fixing" CL (object level confinement)
ansible at xnet.com
Wed Sep 21 05:59:31 EDT 2005
[BTW, sending this to e-lang because it seems more general.]
OK, so many thoughts, so little time.
Towards the goal of writing down those thoughts, so that they might
actually be useful to and debated among other people, I need/want to
push out several e-mails on the following topics:
* More comments on the Common Lisp package system.
* Object level, package level, and image level confinement in CL.
* Image level confinement with CL, and how this could be really cool and
* More on why I like CL.
* Why or why not Scheme? (still an open question for me, again)
* Fixing Scheme:
* Scheme package / module systems.
* Scheme R5RS vs. object-level confinement.
* Scheme 48 and other implementations.
Here are some comments in response to Jonathan Rees' e-mail about
object-level confinement. (Thanks David)
Jonathan Rees wrote:
> I think this is a herculean task. Good luck. There are scores of
> features in Common Lisp that show abysmal capability discipline. This
> is one thing that led me to give up on it (I worked on the first
> Common Lisp implementation, NIL) and do T and Scheme 48 instead.
Indeed. I am despairing of trying to get any kind of object level
confinement in CL. More on this below.
> I always had in mind the goal of running multiple mistrusting users in
> a single address space, which is tantamount to capability security.
> While this has never happened in a serious way, it would be very easy
> to do a capability-disciplined Scheme 48 if anyone cared to. E.g.
> pairs are mutable in Scheme 48, for compatibility with the Scheme
> report, but it is easy to remove set-car! and set-cdr! from the
> namespace with little change in functionality. (You'd have to rewrite
> list-sort and some other things that use them internally.)
I'm of two minds with this.
On the one hand, I'm OK conses being mutable by default. As long as
there is a way to make a particular data structure immutable, then it
can safely be passed to other not-so-trusted functions.
In CL, I was envisioning a set of routines to easily enable this:
FROZEN - returns an immutable copy of the object or data structure
DEEP-FROZEN - recursive version of FROZEN
NFROZEN, DEEP-NFROZEN - these directly operate on the passed object(s)
making them immutable.
Scheme versions would follow a different naming convention, of course.
On the other hand, Mark Miller recommends that conses be immutable by
default. If we're changing stuff to make a given language (CL, Scheme
or whatever) follow full capability disipline at the object level, we
could change this at the same time.
> Let's see... you'll have to make GET local to a lexical namespace
> somehow, and OPEN... and Lisp INTERN has the same problem that Java's
> does - if you can detect the internedness of a string then
> confinement is impossible. I guess you already ditched dynamic
> binding, catch and throw, and the condition system. And there are
> tons of things that are similar to GET in that they access global
> state - logical pathnames, readtables, defsetf, properties on keyword
> symbols, etc. Were you going to make packages be the atomic security
> domain, so that each had its own GET and so on (in effect a separate
> address space)?
I was wandering towards package level confinement for CL. I'm starting
to think of a package as a kind of closure itself. If that makes sense.
I hadn't already ditched dynamic binding and those other features yet,
but that does bear a lot of thinking. I'm sure I don't know as much
about CL as others on this list either.
> I'm using Common Lisp now so the horrors of the package system and
> the rest of the language are fresh in my mind. I think your eventual
> language won't be recognizable as Common Lisp, but it will be much
And that's the main issue.
I've been struggling with trying to give CL greater capability security
for a couple reasons:
* There's a lot of good design in CL. There are a lot of feaures I
really like. And there are a lot of deep, subtle interactions between
all the various parts which have been worked out over the years.
* If you want to do real-world application development in Lisp, your
first choice is probably going to be CL. It is the biggest Lisp. It
has the most high-performance and complete implementations. And it has
the most libraries which work in more than one implementation.
But if it isn't possible to maintain 90% source compatibility with CL,
then it isn't going to be useful, at least as far as adapting / taming
the existing libraries.
And then falling back to image level confinement is the only reasonable
option in this direction.
Thanks for sharing, everyone.
More information about the e-lang