i was about to reply to the author of the 32bit uid patch,
thinking that this should not change lightly, but should
wait until some discussion on extensible authorization spaces.
'scap' is one of the forms i'd expect this to embrace,
with a 64bit (or more??) capability space which maps down
to a 16bit {User,Group,Vol,Session,Xaction,...}Id when queried
thru the old interfaces.
treat this like the move from IPv4 to IPv6, where several
sub-namespaces Embrace & Extend (TM) the old ID space.
designing a fully secure ID space which can serve all needs
is a real can of worms, and we should explore/consult before
unsettling linux/glibc futures by another little change,
when the same porting hassle can be delayed until we get
a more powerful featureset in place (as long as it can be
seen to have a minimal bugset).
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/