|
From: Adam L. <ag...@li...> - 2000-03-05 17:01:08
|
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.
|