[elysium-developers] Capabilities

[Rogelio M. S. Jr. <ro...@ev...>]

>If capabilities are to reside in - unprotected - user space we'll need

>to use encryption, but AFAIK revocation isn't easier with encrypted

>capabilities than with clists in kernel space (IMHO it would be easier

>with the kernel controlled clists).

>

>/Kasper

OK I see it now. We don't have other abstactions to use like "ports" in
Amoeba and we would have a problem with randomizers and seeds and all.
And encrypion would need to use lengthy computations to be secure.


Quote from AGL:
_____________________________________________________
Well, I'd suggest using real 'capabilites', not EARs.

Let me try something like this:
struct cap {
    int obj_type;
    int obj_id;
    int obj_meth;
    int access;
};

'int' might not be the right datatype for some of these, but that's not
important right now. This system encodes an object and an access. The
@acce=
ss
field would be a bitmap like:

#define CAP_READ   1 << 0
#define CAP_WRITE  1 << 1
#define CAP_DELETE 1 << 2
#define CAP_APPEND 1 << 3

etc...

The @obj_type would be something like process, mem_page, I/O port etc.
The=
=20
@obj_id would define the actual process, memory page or port etc. The=20
@obj_meth would be one more level (like the method of a server).

A process would be granted capabilies when it started, in well known
table
indexes. Like STDIN, STDOUT and STDERR are fd 0, 1 and 2 in *NIX.=20

Lets say a process wanted to give another read-access to one of it's
pages.=
 It
would make a capability.

obj_type =3D CAP_MEMPAGE
obj_id =3D <the page number>
obj_meth =3D 0   /* Not used */
obj_access =3D CAP_READ

It would then send this to the kernel. The kernel would check that it
had *=
at
least* read access to the page, and give it the capability (returning
the i=
ndex
id). It could then give the capability to the other process, like you
descr=
ibe.

For another example: a server.

The server generates the capability:

obj_type =3D CAP_PROCESS
obj_id =3D get_pid()
obj_meth =3D MY_SERVER_METHOD_READ;
access =3D CAP_READ | CAP_WRITE

It could then give the capabilites to any process it wants. When they do
a =
PCT,
they (via the kernel) present the capability. The server checks the
obj_met=
h and
access fields and does the requested work.

This (IMHO) is a far better system. I would recommend this paper:
http://www.eros-os.org/essays/capintro.html

As good reading.

AGL
_______________________________________________________

I Agree:


 Thus:
	a.The c-list would be in read-only in shared space.
	b.The capability key-ring is also read-only in processes, modifiable
only by the kernel.


RMSJ