[cap-talk] Importance of fd based library API extensions?
Jed Donnelley
capability at webstart.com
Mon Jan 14 04:49:14 EST 2008
At 01:07 AM 1/14/2008, Rob Meijer wrote:
>Working on some texts concerning the subject of POLA/POLP usage
>on mainstream operating systems using the multi process approach,
>I came to the insight that the main obstacle to this approach
>seems to have not much to do with incomplete kernel mechanisms or
>legacy 'program' code, but actually much more with the simple fact
>that existing 'libraries' mostly 'insist' on opening their own files,
>sockets, directories etc.
Hmmm. From my perspective I appreciate your insight, but I believe
the above somewhat overstates the case. Suppose there were libraries
that accepted object references (e.g. open file descriptors) instead
of names for files and didn't insist on opening their own files as
you suggest. Wouldn't there still be a problem with legacy code
that manipulated file names rather than descriptors at many other
levels?
Also, even if programs communicated open file descriptors essentially
as capabilities, with current OS kernels such programs would still
be running as some "user" and would have the authority to open
files available to that user ambiently (i.e. without needing a
capability). This is not POLA/POLP.
>This results in new programs that would want to use least authority
>in their design (using the multiple process approach)
You lost me with that phrase "the multiple process approach" as you
did in your opening paragraph when you said "using the multi process
approach". Can you explain what you mean by that expression?
>would thus not
>be able to use the great amount of existing library code.
>
> >From the point of view of library developers it would in most cases seem
>like a minor effort to extend the library API to not insist on opening
>sockets, files,directories etc.
A rather minor effort in the code perhaps, but the fact that the
API for the library would have to change I think is major.
>I am very interested to know if others share this insight, and if so, if it
>would be important/useful for us to actively advocate this approach to
>library API's ?
I think I generally agree with the above position, though I would
say that this is a case where the devil is in the details.
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list