Post by a***@speakeasy.orgI'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.
Post by a***@speakeasy.orgWe 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.
Post by a***@speakeasy.orgVLservers 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-***@cell
and afs-***@cell). Clients which support this feature should try the
new keys first, and then the old ***@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 ***@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 ***@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 ***@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