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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
