> 
> > How do you solve access control
> > problems and concurency (transaction...).
> 
> Access control via ACLs.  There was a comment on this list that capabilities
> were a better way to go and don't require VM changes provided you lock out
> certain primitives; having done this once with source-code restriction on
> VisualWorks, I disagree and feel that VM changes are required as you cannot
> lock out the primitives and still provide acceptable debugging.  I'm working
> on this, but am stalled due to the current object header format.  I suspect
> I won't be able to do much more until/unless Tim's NCM format gets merged
> into the main development stream.  More details on request; I actually have
> some design documentation on this!


When I posted earlier about capabilities, I said what you say here:
you don't have to make any VM changes, *except* to support debugging.
And you can leave traditional debugging turned on while you develop
the system, leaving the VM mod for the last step.

Also, the needed changes to support debugging are tiny: you just need
to be able to obtain the class of an object, and to peek and poke
instance variables.  Instead of instVarAt:, you'd have #instVarOf:at:.
Likewise for #class and #instVarAt:put:.  I can email support for this
to anyone who wants it, but it's very easy: just modify
#instVarAt:  into #instVarOf:at:, and so on for the other
two primitives.

As far as multi-user systems go, consider that just because you have
usernames and passwords, doesn't mean that you have to use ACLs.
Instead, you could provide each user with a "home directory", a "public
directory", and a handle to all other users' public directories.  Such
a system seems simple to implement and simple to work with.

Let me sketch three advantages to using capabilities over ACLs.

On the low end, capability systems are, IMHO, a lot easier the
reason about than ACL systems.  If you want people to be able to use
something, then put it in your public space.  If you don't, then leave
it in your private space.  If you want to give them read-only access,
then put a read-only wrapper of the object in your public space.

On the high end, a capabilities model allows you to have cooperating,
un-trusting programs.  ACL systems have a much harder time of this,
except when they graft capabilities on top and use something like
sockets.

In the middle, you can make much more complex access policies than
read/write/execute.  For instance, you can supply a morph wrapper which
can display the underlying morph, but which cannot send input to the
morph.  Thus you could display someone's screen without being
able to modify it.

Oh well, I'm no expert on security, and traditional ACL systems
certainly do poke along and do their jobs okay.  But there really seems
to be a better way to organize multi-user operating system security.
The technology is here, and the material is on the web; if you are
interested in making a new security system, then it seems worthwhile to
go read the newer stuff and implement it, instead of just sticking with
older systems.


Lex

PS -- it's worth considering how often you really need protection
between the multiple users.  Are people on your system really going to
be messing up each others' stuff?


PPS -- along with the above, who is going to maintain all the security
settings to make sure each user is protected from the others?  If they
slack off, and leave some hole open, will anyone ever notice?

PPPS -- along with these, consider that most security-concious Unix
admins don't really expect security between users to be perfectly
maintained, even with a well-adminned system.  When they really care
about protecting some process or whatnot, what do they tend to do?
They put it on a completely separate computer.  Capabilities would help
somewhat, but I think the deeper issue is that security within a
computer is complex and very hard maintain in practice, unless you want
to spend more time working on security than on improving
functionality.