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

[Gergely Risko]

On Tue, 18 Mar 2014 11:31:50 -0500, Andrew Deason <adeason@sinenomine.net> writes:

> On Tue, 18 Mar 2014 16:27:45 +0100
> Gergely Risko <gergely@risko.hu> wrote:
>
>>   - 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,
>
> What you're really checking is just that the connection is
> authenticated; rxkad_GetServerInfo will always return success for a
> properly authenticated rxkad connection.
>
> With krb5 and rxkad, that only means the client was able to present a
> valid AFS service ticket. It also doesn't have to just be
> authuser+foreign, since you can check if they are a "non-foreign user"
> by checking the realm, which we already have logic for.
>
> However, that doesn't verify that they are a valid AFS user at all; this
> is more of a kerberos-level check than an AFS check. The user may
> deliberately not have an associated ptdb entry (so they are effectively
> unauthenticated for all normal operations), or they may be a foreign
> user from a realm that the AFS administrator did not configure "foreign
> user" access for.
>
> That is specific level of "access" that I don't think exists anywhere
> else in AFS; it doesn't have an equivalent in current normal operation
> and may be confusing. The meaning of such an access check could also
> change for non-rxkad security classes.

Hmm, okay, yes, and it seems very week, so I certainly don't want that.

But then our only option left is to check for the realm, right?  I mean
without introducing a ptserver ubik client.

Should we do that?  And warn administrators in the manpage that this
restricted access is not compatible with foreign users?  Better options?

Gergely