[OpenAFS-devel] Initial implementation of RestrictedQuery, please comment

[Jeffrey Hutzelman]

On Wed, 2014-03-19 at 00:42 -0400, Jeffrey Altman wrote:
> On 3/18/2014 10:38 AM, Jeffrey Hutzelman wrote:
> > On Tue, 2014-03-18 at 09:29 -0400, Jeffrey Altman wrote:
> > 
> >>>     - of course you can't access membership listing and other ptserver stuff.
> >>
> >> Fyi, self service group membership management is one of the hallmarks of
> >> AFS.  Restricting access to system:authuser + foreign is necessary if
> >> you wish to permit users to define and manage personal groups.
> > 
> > However, this is much easier to do in the ptserver, which owns the PRDB
> > and already uses PRDB lookups as part of its authorization process, than
> > it would be in the volserver or vlserver, which have no relationship
> > with the ptserver (and for which requiring such a relationship could be
> > operationally undesirable).
> 
> My 2012 proposal that was referenced in the first e-mail assumes that
> a relationship between the volserver and vlserver to the protection
> database would happen.  Otherwise, it isn't possible to provide ACLs on
> entries to control different levels of access.
> 
> >> Its not that complicated unless you want to set separate permissions for
> >> each remote Kerberos realm.  If the levels are authuser localonly and
> >> authuser remote then the difference is a test for membership in
> >> system:authuser or a test for a non-anonymous AFS ID.
> > 
> > A volserver or vlserver cannot easily test for membership in
> > system:authuser, and does not know the client's AFS ID.  Changing this
> > would be a _much_ more complex patch, since it would require something
> > analogous to the fileserver's hpr package.
> 
> The HPR package can be turned into a library which could be linked to
> the other services.

Yes, this can happen, and I think we're all agreed that it will need to
happen eventually.  However, I think the point of the current discussion
is to give some control now, without having to wait for what is a fairly
complex change.

> In this case a volume query or
> a file query may be presented to the AFS cache manager by ID and the AFS
> cache manager will have to query the volume location database by ID to
> retrieve the data.   The CM will use VL_GetEntryByName* to do so.

OK, so Windows does not call VLGetEntryByID* either, then?
This is sort of a moot point, since there is little purpose in
restricting the by-id RPC interface when the necessarily-unrestricted
by-name interface provides a superset of its functionality.


> >> Reviews should be performed in Gerrit.
> > 
> > Reasonably complete patches should be submitted to Gerrit for review and
> > integration.  Design discussion is more appropriate on this mailing list
> > than in review comments in Gerrit, which are terrible as a
> > general-purpose discussion medium.  This thread is just crossing the
> > boundary from one to the other, _if_ we assume general agreement on the
> > scope of the change (for example, not adding features that would require
> > PRDB lookups in the volserver or vlserver).
> 
> The recommendation was to use Gerrit because a working patch was
> provided for review in github.  If reviews of the patch are to take
> place, it would be best that they be done in Gerrit.

Agreed.


> Semantics changes to RPCs in general should not take place.  New RPCs
> should be issued if the behavior of the RPC is going to be modified.

That's only necessary for _backward-incompatible_ changes, and not
always even then.  Particularly for RPCs that have been around ~forever,
making this determination can be challenging, but is sometimes
necessary.  One of the changes proposed in this thread was for certain
RPCs to return false volume names, possibly only to unauthenticated
callers.  That's certainly a semantic change, and possibly a
backward-incompatible one, but maybe not one that would actually break
interoperability in a way we care about.  It's also a change that is
completely pointless to do in a new RPC while leaving the old one
alone.  


> Such discussions do belong in afs3-standardization if those RPCs involve
> cache manager interactions.   If the RPCs are in the group of those RPCs
> that are considered to be administrative or server to server, then they
> do not necessarily fall under the afs3-standardization process.

We've never really sat down and drawn a sharp line around which things
are part of the standardized protocol suite and which are not.  For the
most part, I don't think we need to do so.  The only purpose of such an
exercise would be to forbid implementors from doing certain things
without taking them to afs3-stds, which wouldn't be binding on anyone,
or to impose prior restraint of discussion of certain topics on
afs3-stds, which I'm not willing to do.

That said, any time interoperability concerns arise, the topic is an
appropriate one for afs3-stds, even if it turns out not to be an
appropriate one for actual standardization.  Also, IMHO it is better to
start such discussions earlier rather than later.  You don't need a
fleshed-out spec to start discussing a topic on afs3-stds, and you
certainly don't need an implementation.


-- Jeff