[cap-talk] POLA for builds (was: ACLs not inherently bad)

[Jed Donnelley]

cap-talk,

I changed the subject for this thread as I see it as addressing a
rather small subset of the larger "ACLs not inherently bad" topic
of resolving POLA with large shared directory structures.

For this subset, I believe the topic is how to manage POLA
for builds for program development (BillF's make/GCC example)
where there may be large numbers of files involved:

At 10:40 AM 9/17/2008, Jonathan S. Shapiro wrote:
>On Wed, 2008-09-17 at 10:24 -0700, Jed Donnelley wrote:
> > 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:
>...
> > > > 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."
> > > >
> > 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.
>
>For the environment of binary programs this is true, but things like
>make definitely need write access to the build directory, and the build
>directory is usually somewhere under the per-user tree, so this
>constitutes shared write access with the world at large.

Sorry, but I don't understand why the build directory needs to be shared
with the world at large - whether read-only or read-write.

One thing I didn't mention before is that there have been systems
developed (many?) on a capability infrastructure that did program
development with these same needs and that didn't run into problems
with differing access to shared directories.  Our NLTSS system
was an example.  In the NLTSS system there were indeed large
numbers of files that were shared publicly read-only.  When
anybody was doing program development ("make") all those public
files were available in a hierarchical directory structure.  The
build directory was read-write for the user (person) doing the
build - as it seems to me it should (must?) be.  The process
of putting together the trusted pieces of the public libraries
must (it seems to me) be managed by somebody trusted with the
vetting of such an assembling - e.g. along the lines of the
mechanisms required for putting together a Linux distribution.

> > 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.
>
>In practice this doesn't arise in make, because having two users build
>in a single tree tends to generate inconsistent results.

I think that was my point above.  At least I don't see an argument that
suggests there is a requirement for shared write access to a build directory.

>But now that I think about it, a multiuser-shared ccache directory is a
>nice thing to have.

I expect there is a terminology issue hidden in the above.  Of
course there is no problem in capability systems having multiple
"users" share write access to a directory and having other
"users" sharing read-only access to that same directory.  In
such a case the directory server may well provide a multi-user
cache facility.

Beyond the above I believe we are back into the broader question
of whether there is a legitimate need for shared access to a
common directory graph where some "users" (read as an initial
reference into the graph) get one sort of access and others
get a different sort of access.  This is back to the broader
thread of "ACLs not inherently bad" that I've mentioned I would
like to take up again interactively at HP on Friday.

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