peter swain wrote:
> i'd be interested in exploring such things.
> Some possible features include:
> * 16bit uids are represented internally (when id16to32() mapping
> is applied) by an (id, time, rights) tuple, so anything uttering
> an old id16 can encapsulate a snapshot of its intention.
> Imagine 'kill -TERM --capability 3456' returning a string which
> will enable the holder to SIGTERM the *current* proc 3456 at any
> time in its life, but not any future proc 3456 (after 2^16 more
> forks have wrapped the pidspace).
> * such alien id-spaces as Win32/NT ids, NFS-handles, (dev,inode) pairs,
> yadda yadda, could be candidates for wrapping in some subspace of
> IDng (TM,GPL) capabilities
> * possible merge of capability-spaces, routing-spaces, fd-space,
> into some kind of simple computational structure
> * incorporate Beowulf clusterwide-mock-PID extensions
> * have a small cache of translation/authorisation entries which
> (on some architectures) get hardware assist (x86 task/entry/... gates,
> MIPS TIDs, whatever), but not at the expense of uglifying the generic
> case.
> * unify capability passing with the send-FD-over-socket stuff
> * unify capability handling with FS ACL handling
> * unify capability handling with fairshare scheduling (such as Aurema's
> forthcoming ShareII port to Linux, and a freer project which developed out of
> bandwidth-allocation research, but whose name escapes me)
>
> has anyone beaten this topic to death as infeasible,
> or should we try now???
>
> ^..^ swine@pobox.com
> (oo)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
--Casey Schaufler voice: (650) 933-1634 casey@sgi.com fax: (650) 933-0170
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/