[OpenAFS-devel] openafs cell and contrib area?

[aeneous@speakeasy.org]

hutz,
I like your ideas about the trust model in general, but I also had the 
following simultaneous thoughts -- not all entirely compatible with each other 
-- but they're the first things that come to mind:

- I think you're biting off too big a chunk for the first pass at something 
like this.  Start with splitting security:administrators off from 
system:administrators, which is easy, and maybe add a couple of more flexible 
options for volume ownership. The other bits of "user A can create volumes on 
server S but not server P" can be handled simply as a matter of policy, in 
most cases.

and.

- what does it mean to say "database server operators are not forced to trust 
each other", when the fact is, there's no point in cooperatively sharing a 
database with someone who you don't trust completely.  Really, trust means 
simply "trust to update the {volume,backup,xxx} database", right?

and.

- the problem of cooperating with regions under separate administration was 
why cells were invented.  (that, and the fact that inventing cells was Quick 
And Dirty).  Aesthetically, I'd like to see a new model hew as closely to the 
old one as possible.  Simplicity *is* a virtue.

and

- anyone who has admin permissions on the V.1.1 fid in a volume should be able 
to release it. To anywhere.  This is as good a definition of "volume admin" as 
we need.  It does mean that the volserver would have to be able to interpret 
ACLs, which is new, but the code is very modular...

and

- the flexibility is useful, even if you can't get perfect subdivision of 
authority.  I'm willing to accept that Joe can frig with Bob's server 
somewhat, for instance, by releasing volumes which are replicated in both 
places.  That's awfully minor, and if Bob doesn't like it, then he can put his 
own resources in his own cell, or remove the local replica on his server, or 
write a script to remove it every 5 minutes.

Ok, random ramblings, granted, but let's see who hates 'em.