[OpenAFS-devel] openafs cell and contrib area?

[Jeffrey Hutzelman]

On Fri, 3 Nov 2000 aeneous@speakeasy.org wrote:

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

OK; that seems reasonable.

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

That works for me.

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

Hm.  That's an interesting approach, and possibly a good change for most
cases.  But I don't think it addresses the issue of separating fileserver
admins.


Let me try to present the problem in a different way.  Carrying over the
terminology we agreed on above...

(1) Each cell has a number of database services - authentication
    (kaserver), authorization (ptserver), and volume location.  These
    services may be run by the same or separate groups, but they
    presently share the same service key, and thus anyone which access
    to that key has privileged access to all three services.  As you
    mention above, these services should use separate keys, to make them
    separable.  While this is a desirable feature, I don't think it is
    required by the openafs cell.

(2) The database services must run on multiple machins, for redundancy.
    In a cell like openafs.org, it is desirable that these machines be
    widely geographically distributed.  It is also desirable that they
    be able to be operated by administrators at the sites at which they
    are located.  Thus, it is desirable (and, IMHO, required for the
    openafs.org cell) that the operators of one dbserver machine need
    not trust the operators of another.  It is also desirable that the
    operators of such machines need not trust the operators of the
    services that run on them.

(3) It is desirable, but not required for openafs.org, that those who
    have privileged access to the filesystem contents not automatically
    get access to the authorization service.  Presently, these two are
    both tied to membership in the system:administrators group.  Note
    that it is practically impossible to prevent prdb admins from getting
    access to any filesystem object they want, but it may be worthwhile
    to make that not automatic.

(4) Each cell has a number of fileservers, which consist of a machine
    running the viced and volume services.  It is desirable that the
    operators of these machines and services need not be trusted by
    the cell admins, except with the content of volumes stored on them.
    I see this property as being critical to a cell like openafs.org.

(5) It is desirable that the cell admins need not be trusted by the
    operators of fileserver machines, though they must be trusted by
    the operators of the services on those machines.  Again, I think
    this is important for openafs.org.


(1) can be accomplished by creating separate service principals for the
authorization and volume location services (something like afs-prdb@cell
and afs-vldb@cell).  Clients which support this feature should try the
new keys first, and then the old afs@cell key.  Supporting old clients
is a bit trickier.  It is probably OK for the vldb service to require
new clients, since only admins need authenticated access.  The prdb
service presumably must accept connections authenticated using the
old afs@cell principal.

The authentication service already uses separate service keys, so there
is no problem to be solved there.

(2) and (5) boil down to allowing only server administrators to have
privileged access to a machine.  This can be solved by taking several
steps...
  - Don't run database services as root
  - Make the bosserver use a separate, per-machine key
  - Allow the bos exec, install, and getfile commands, and all
    forms of remote configuration, to be disabled at compile time
    or by a command-line switch.

(3) is accomplished by splitting system:administrators into two groups.
Unfortunately, it is hard to allocate a new distinguished group ID, so
the system:ptadmins group should be looked up by name when the ptserver
starts.  Similarly, it may be desirable for the set of vldb admins to
be represented by a pts group, which would also be looked up by name.
I see no reason why the volserver and vlserver can't use GetCPS.

(4) basically requires that each fileserver use a separate service
principal, instead of a common one.  I would suggest that such principals
be named afs-fileserver.<fqdn>@cell, but it has been suggested to me
that this would require the cache manager to do DNS lookups, which is
not desirable.  I remain open to other ideas.

Backwards compatibility for fileserver clients using the afs@cell
principal is a pain.  The hackish approach I see is running a service
on the database server machines that will reveal the session key for
a particular afs@cell connection to authorized fileservers.  Obviously,
clients who use the old principal will be subject to snooping by
operators of fileserver services, but there's little that can be done
about that.


It has been pointed out to me out-of-band that all of the complicated
volume-level permissions that we discussed can and should be handled
by a privilege-delegation service, instead of being wired into AFS
itself.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA