Re: 'native files', 'object fingerprints' [was: sendpath()]

From: Ingo Molnar (mingo@elte.hu)
Date: Tue Jan 16 2001 - 06:26:12 EST


On Tue, 16 Jan 2001, Andi Kleen wrote:

> On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
> > this is a safe, very fast [ O(1) ] object-permission model. (it's a
> > variation of a former idea of yours.) A process can pass object
> > fingerprints and kernel pointers to other processes too - thus the other
> > process can access the object too. Threads will 'naturally' share objects,
> >...
>
> Just setuid etc. doesn't work with that because access cannot be
> easily revoked without disturbing other clients.

well, you cannot easily close() an already shared file descriptor in
another process's context either. Is revocation so important? Why is
setuid() a problem? A native file is just like a normal file, with the
difference that not an integer but a fingerprint identifies it, and that
access and usage counts are not automatically inherited across some
explicit sharing interface.

perhaps we could get most of the advantages by allowing the relaxation of
the 'allocate first free file descriptor number' rule for normal Unix
files?

> Also the model depends on good secure random numbers, which is
> questionable in many environments (e.g. a diskless box where the
> random device effectively gets no new input)

true, although newer chipsets include hardware random generators. But
indeed, object fingerprints (tokens? ids?) make the random generator a
much more central thing.

        Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Jan 23 2001 - 21:00:12 EST