[for want of a better place I post this here]
With OmniBase finally available under Squeak (/me pats: self on:
shoulder), I've started work on the content management system (and more)
that will, hopefully, run my cdegroot.com website some time this
century. For now, there's some marginal information on
http://swiki.squeakfoundation.org/sea/66 - it's still too much
vapourware to start a website for.
Anyway, if you read the design note on
http://swiki.squeakfoundation.org/sea/75, you will notice that I'm
planning to make Sagan completely free of ACL's. And as I don't want to
make the mistake of slapping security on as an afterthought, I'd like to
sollicit any ideas before commencing work on this layer.
The basic idea I have is that you are always known to the system as a
user - where most users will all start out sharing the same 'anonymous'
user, with a sort of 'copy-on-write' mechanism creating a private set of
capabilities as soon as the user gets new capabilities. The capabilities
are kept server-side, the user can access them by authenticating (by
whatever means - probably I'll start out with a cleartext password on an
unsecured connection ;-)). Capabilities are persisted, of course, in
OmniBase.
Ideally(?), there would be a mesh of capabilities between the m users
and the n objects to protect. However, I fear that this m*n number may
be a tad unmanagable for, say, 1000 users and 10,000 protectable
objects.
So, the first thing I'm looking for is ways to lower this count, maybe
by grouping objects in some way and handing out a single capability to
them, etcetera. Questions to be answered: can this be done without
impairing either security or user-friendliness? If yes, what is a good
basis for this grouping?
The second issue, more down-to-earth, is how to implement capabilities.
On an object with n methods, you can theoretically hand out
n
--
\ (n)
/ (k)
--
k=1
different capabilities ("\[\sum_{k=1}^{n} \left( \begin{array}{c}n \\ k
\end{array} \right)\]" if you're into LaTeX). That's a tad high to
resolve with static classes. So some sort of dynamic wrapper must be
made to represent capabilities, and it must be lightweight and space
efficient, because Sagan is going to store lots of them.
I had a third issue, but an incoming phone call popped that off the
stack.
The Usenix Security 2003 Conference rejected our paper, "Capability Myths
Demolished" http://zesty.ca/capmyths/usenix.pdf . The rejection is posted at
http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html , which is
also the root of a thread at which we'll be discussing our failure to
convince, and what we should do about it. If you're interested, please read
the thread and join the discussion.
----------------------------------------
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
Yay! That's awesome news, Lex.
Rob
> -----Original Message-----
> From: Lex Spoon [mailto:lex@cc.gatech.edu]
> Sent: Friday, March 14, 2003 4:59 AM
> To: The general-purpose Squeak developers list
> Cc: squeak-e(a)lists.squeakfoundation.org
> Subject: [Squeak-e] Islands image has been retrieved
>
>
>
> Okay, a very kind soul has obtained my old files from a Disney backup
> archive. You can now download a pre-loaded Islands image as
> well as an
> interp.c that has the necessary primitive changes. Look for
> "lex-sandbox.zip" on:
>
> http://minnow.cc.gatech.edu/squeak/2074
>
>
> Lex Spoon
> _______________________________________________
> Squeak-e mailing list
> Squeak-e(a)lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeak-e
>
Okay, a very kind soul has obtained my old files from a Disney backup
archive. You can now download a pre-loaded Islands image as well as an
interp.c that has the necessary primitive changes. Look for
"lex-sandbox.zip" on:
http://minnow.cc.gatech.edu/squeak/2074
Lex Spoon