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

[Jeffrey Hutzelman]

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

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



> > I also have some new questions, maybe a bit controversial:
> > 
> >   - would anything break if we wouldn't return the volume name when the
> >     GetVolumeByID is used if you're unauthenticated?
> 
> Yes.  Cache managers that lookup volume group data by ID would not be
> able to hash the data by the name.   This would result in multiple
> volume group entries for the same volume group in the Windows cache
> manager.  There would be negative impacts on volume callback processing.

Cache managers are supposed to look up volume group data by name, not
ID.  This is why VL_GetEntryByName*() support lookups of "names" that
look like volume IDs.  The UNIX cache manager behaves this way and
always has (or at least, it has since there _was_ a separate volume
location service).  Does Windows do this differently?


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

However, I should point out that discussions regarding making semantic
changes to RPCs, _especially_ when those RPCs are used by cache managers
and other AFS client implementations, belong on the afs3-standardization
list, not here.  The readership of the two lists is not the same, and a
message sent there raising the possibility of locking down RPCs that may
be used by clients could well raise objections that would not be
mentioned here.  For example, the author of afscp, which was mentioned
earlier in this thread, follows that list, but I don't think he pays
attention to this one nearly as often.

-- Jeff