Re: [elysium-developers] Capabilities revisited

[Adam L. <ag...@li...>]

On Sun, Mar 05, 2000 at 05:07:29PM +0100, Kasper Verdich Lund wrote:
<snip>
This looks about right, except:

> Restricting Capability Use
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> There might be situations where a process wants to give a capability to
> another process, but wants to make sure that the capability cannot be
> duplicated or transferred. By extending the capability data structure to
> with a cap_perm field it's possible to handle this situation. The
> sys_duplicate_cap() might be rewritten to something like:
>=20
> int
> sys_duplicate_cap(uint32_t ci, uint32_t nperm, uint32_t nci)
> {
>   <<check that (C-list[ci].cap_perm & CAP_PERM_DUPLICABLE) !=3D 0>>
>   <<.... as before ....>>

This is against the principle of capabilitys. If you give something a capab=
ility you trust it to use it. You thus trust it not to pass it on. I don't =
think this is needed

>=20
> of I/O ports we need to make sure that the (id,type,owner) tuple reveals
> the exact range of I/O ports in a simple way.

Given that the only think a kernel knows about a capability is in the cap s=
tructure, we can't fail to do this, unless we use weird lookup tables. if w=
e do, we must allow them to be mapped (read-only)

AGL

--=20
Smoking is one of the leading causes of statistics.