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

[Andi Kleen]

On Tue, Jan 16, 2001 at 12:26:12PM +0100, Ingo Molnar wrote:
> 
> 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.

Actually on second thought exec() is more a problem than setuid(), because
it requires closing for file descriptors.

So if you could devise a security model that doesn't depend on exec giving
you a clean plate -- then it could work, but would probably not be very
unixy. 

I'm amazed how non flamed you can present radical API ideas though, I even
get flamed for much smaller things (like using text errors to replace
the hundreds of EINVALs in the rtnetlink message 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?
Not sure I follow. You mean dup2() ? 

-Andi