[cap-talk] More Heresey: ACLs not inherently bad

[Jonathan Smith]

Similar considerations make process migration hard in UNIX.
-JMS

On Sep 1, 2008, at 2:37 PM, Jonathan S. Shapiro wrote:

> On Mon, 2008-09-01 at 11:09 -0700, ihab.awad at gmail.com wrote:
>> On Mon, Sep 1, 2008 at 10:55 AM, Jonathan S. Shapiro <shap at eros-os.com 
>> > wrote:
>>> The real issue is that the kinds of things that we generally  
>>> forget are
>>> actually parameters: like the space of dynamic libraries...
>>
>> Sorry I didn't parse "the space of dynamic libraries".
>
> Umm. Sorry. I should have written "name space of dynamic libraries".
>
> My point is that the execution environment of real-world applications
> tends to involve a very large number of objects that are  
> conventionally
> organized using hierarchical name spaces (directories). It is only
> simple to provide these environments if the name spaces are conveyed  
> to
> the applications as a single "root" capability. If selectivity becomes
> necessary, filtering at exec time becomes a burden on program startup,
> and it becomes better to filter dynamically.
>
>> Are you talking about the ability to load (presumably powerless)  
>> code...
>
> No code is powerless. Dynamically loaded code that is loaded by a
> sensitive application is actually very powerful.
>
>> That can be provided by a suitably
>> configured module loader. Yes that might need some sort of a
>> namespace. But making it explicit is great since now (!!) you can  
>> have
>> co-existent multiple versions of lib{foo} without worrying about how
>> the global namespace gets polluted.
>
> I am very much in favor of making the name space explicit. My primary
> point is that if you *do* make the name space explicit (e.g. by making
> the descriptor to "/" an argument to fork() in UNIX), you have  
> achieved
> most of what you are going to get out of capability systems in real
> practice.
>
> Couple this with I_SENDFD, and one can readily imagine a system that  
> is
> 96% UNIX compatible at the source level and much more securable than
> current systems.
>
>
> shap
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk