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

[Gergely Risko]

On Tue, 18 Mar 2014 10:38:39 -0400, Jeffrey Hutzelman <jhutz@cmu.edu> writes:

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

Yes, I just realized and came back to my email buffer to say it :)

I think the following levels can be differentiated with reasonable ease:
  - no ticket, not authenticated at all (userok.c line 367),

  - authenticated: in userok.c line 391 rxkad_GetServerInfo succeeds, in
    our current thinking this is authuser+foreign user, right?  Someone
    who is not related at all to the AFS cell shouldn't be able to get
    this far,

  - sysadmin: in UserList file, afsconf_SuperUser returns true.

If we implement it like this, then the only thing we lose is the
"authuser, but foreign not included" case, which seems to be OK.  Can
you guys confirm that just checking for a ticket with
rxkad_GetServerInfo is enough for authuser+foreign?

I'd really not like to code up the vl/volserver -> ptserver dependency.
And I'm not sure that I'd like to have it just for the authuser feature
even if someone would code it up for me.

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

I certainly do want to leave the feature disabled by default.
Nonetheless, if you think it's important, I'm happy to send a summary
proposal to the standardization list when we have the first working and
acceptable prototype.  I don't want to start with the standardization
since I'm not experienced enough to notice things like the vlserver ->
ptserver dependency.

Gergely