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

[Jed Donnelley]

At 05:05 PM 9/16/2008, Karp, Alan H wrote:
>Bill Frantz wrote:
> > alan.karp at hp.com (Karp, Alan H) on Thursday, September 11, 2008 wrote:
> >
> > >I contend the installation endowment is the only time you need to
> > grant O(20+) rights.  Per execution
> > >is always(?) O(1).
> >
> > Consider the example of make and its close friend, gcc. In "mature"
> > systems, the make environment is a (usually undocumented) monster
> > of directories and dependencies. It is majorly daunting to new
> > developers. Trying to apply POLA to that environment sends me
> > screaming to, "Just give make everything and lets get on with
> > life."
> >
>Good example, but there are two caveats.  Often, the rights can be 
>collected in O(1) directories.  When that's not the case, you still 
>need to designate the files involved.  I bet someone else (Nothing 
>is impossible for the person who does not have to do it.) can write 
>a Perl script to parse makefiles and provide the appropriate 
>authorities to the process running make.

It seems to me that's equivalent to Bill's "Just give me everything".

One point that wasn't mentioned above is that "everything" here is 
everything read-only.  In my experience the many files that programs 
like make/gcc use are legitimately intended to be world readable as 
read-only.  For those I think a shared directory structure works fine.

There are then two cases that derive from such an example that I 
think might be worth discussing:

1.  The case of "who" gets write access to such make/gcc files and 
how.  I believe this is essentially the case we discussed at HP last 
Friday.  Namely that of Jonathan's focus (as I understand it) where 
you have a large directory structure and you want one or some 
"principal"s to have more access to some limited parts of it.  I'll 
let others who proposed solutions to champion them here if desired.

2.  The case where there is a need to limit even read access to some 
files by some principals - e.g. for proprietary code.  It seems to me 
this isn't too different from #1, except that I can easily imagine 
that there would be large numbers of files involved.  Again I'll cop 
out and let others propose solutions (other than Horton) if they have them.

Perhaps it would be worthwhile to focus the attention of one more HP 
Friday meeting on this topic, just to throw as much clarity on this 
subject as we can while it's fresh in mind?  I'd be interested in 
working through some of the details of the proposals discussed last 
Friday.  To my intuition it seems that the solutions discussed have 
the potential to turn into a "rats nest" of partly duplicated 
directory structures with relatively ad hoc references to either more 
restricted or greater access references (capabilities).

I believe this issue is at the core of Jonathan's "More Heresey: ACLs 
not inherently bad" design challenge:

At 02:07 AM 9/17/2008, Jonathan S. Shapiro wrote:
>2. I still haven't heard a credible answer to the sharing problem that
>doesn't reconstruct ACLs.

Is that right Jonathan?

Regarding PLASH:

At 04:19 AM 9/17/2008, Jonathan S. Shapiro wrote:
>On Wed, 2008-09-17 at 11:52 +0100, Toby Murray wrote:
>...
> >  Secondly, I also wonder why something like Plash
> > wouldn't suit your needs, given that it maintains the POSIX interface
> > whilst allowing fine-grained POLA.

I don't understand why dealing with ports is an issue:

>I'm not clear whether Plash can mediate sockets, for example.

However, with regard to:

>Actually, Plash is the thing that gives me hope that a viable approach
>exists. To answer your question directly, the main problems I see with
>plash are that it is incompletely integrated into the system and there
>are elements in classic UNIX that do not fall within the file system
>mechanism.

I don't see how PLASH solves the problem we are addressing for two reasons:

A.  It uses the Unix file system (users, groups, essentially ACLs, 
etc.) for access control when the power boxes are granting access to files, and

B.  Beyond #A I don't see how PLASH can deal effectively with the 
rash of open calls that face it during a make/gcc 
run.  Hmmm.  Thinking about it a little perhaps I can see a solution 
based on the world read-only thought above.  PLASH could have a 
policy of granting read-only access to all of the commonly needed 
library directories.  Does it do something like that?  Some other 
solution?  Even at that it would seem that PLASH will increase 
overhead (significantly?) by requiring the application's open calls 
to go through it, for it to consult its policy, do the actual open, 
and return the file descriptor through the pipe.

I'd be interested to know how make actually works through PLASH.  Anybody know?

Regarding:

At 04:51 AM 9/17/2008, Jonathan S. Shapiro wrote:
>...
>I'm a bit frustrated because it seems that many people here are having
>difficulty with the concept that the world does not consist entirely of
>leaf objects, and that the capability community has not brought forward
>a satisfactory solution to the any graph sharing scenario in which
>different parties must have distinct access rights.

I agree that the above issue is the core of the problem that we are 
discussing.  This is the problem I tried to address interactively in 
last Friday's HP meeting.  There the participants presented a case 
for using a capability based directory structure (non-Horton) for 
addressing this challenge that was convincing to me at the time.  To 
me it makes sense to ask that group to write up something that could 
be posted to cap-talk.  I'll be happy to work to facilitate that effort.

--Jed  http://www.webstart.com/jed-signature.html