[OpenAFS-devel] openafs cell and contrib area?

[Jeffrey Hutzelman]

On Thu, 2 Nov 2000 aeneous@speakeasy.org wrote:

> - 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.

I don't understand what your 'security:administrators' group is supposed
to be for.  All of the major Kerberos implementations, including the
kaserver, have their own ideas about who is an admin.  And the volserver
and vlserver have never used system:administrators -- they use the
superuser list, which is the inflexible bit we're trying to change.


> - 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?

No.  Under the current model, trust means "trust to be allowed to do
absolutely anything on the server machine as root".  If I have privileged
access to a fileserver machine, I can use the AFS key file to forge
tickets that allow me to access UserList-using services as if I were on
that list.  That's what the -localauth switch does.  Combined with the
'exec', 'getfile', and 'install' commands in bos, I can run any program as
root, and read or write any file. 


I'm envisioning a cell where the various machines on which the fileservers
and database servers run are operated by different people, who should not
be forced to allow each other privileged access to their machines.  This
is useful for the kind of cell we're talking about, where fileservers
essentially serve as "mirrors" of each other.  It's also useful for a cell
whose fileservers are individual user's machines in dorm rooms at a
university.


> - 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... 

Unfortunately, it also has the problem that the _vlserver_ must be able to
interpret ACL's, and so must the volservers which don't yet have a copy of
the volume.  That could get messy...  Certainly, the right to perform a
release should depend only on the volume permissions, and not on what
fileservers the RW and RO sites happen to live on.

> - 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. 

Absolutely.  I thought my model addressed that - the only real question is
whether a particular server admin can force a release of volumes with RO
sites on his server, even though he does not have any special rights on
the volume involved.

-- Jeff