[OpenAFS-devel] openafs cell and contrib area?

[aeneous@speakeasy.org]

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

Sorry, I was being vague.  Operationally, having administrative rights to any 
of the servers has been sufficient to get administrative rights to any of the 
others, including security, as you point out.

I'm just saying that the first thing to do is make sure that possession of the 
vldb service key does not permit administrative access to the kadb.

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

right.  We're agreeing here.

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

We may even be able to agree here.  I thought you were saying that vldb server 
1 and vldb server 2 might be operated by different people who don't trust each 
other.  I think that's silly.

Can we agree (in deference to a decade of misguided common practice, sigh) use 
"server" to mean a piece of iron and "service" to mean a possibly-replicated 
process with a single key?

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

VLservers can't interpret the ACLs, they don't have 'em, and they're not on 
the same hardware.  The source volserver would have to make the vldb update 
calls.
It would also have to make the vol rpcs to the target sites.  Vos is a nasty 
tangle, with lots of annoying failure modes that are a veritable PITA to 
recover from when it is interrupted.  Trapping CTRL-C helps, but really, 
*services* are long-running things, client utilities are not.  This approach 
doesn't get messy, it gets clean...

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

I don't think that's necessarily unreasonable, as long as there's some way to 
prevent Bob from having a replica on his server if he starts being a pest 
about forcing releases every five minutes.