On Tue, 18 Mar 2014 17:40:55 +0100 Gergely Risko <[email protected]> wrote:
> > 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. Well maybe, maybe not (I haven't really thought about this much; I'm just providing some info). If you're just trying to prevent "anyone in the world" from executing the relevant RPCs, this does give you the tools to prevent that. At least what you get with that is an identity that is executing those RPCs that you can look at if you discover you're getting hammered or it looks like they're scraping data or whatever. With an anonymous connection, all you have is an IP, which is not great. Requiring an rxkad-authenticated connection would give you a krb5 principal name (possibly restricted to specific realms), which is better. This becomes useless if you can create a kind of anonymous krb5 identity (I think this is possible in some setups? or it's being discussed?), but the krb5 administrator should be able to control that. That's why I would say such an approach "gives you the tools" to prevent anyone in the world from running these RPCs; it doesn't do it on its own. You can look at it like it's deferring the question of authorization to the krb5 setup. That's not "proper" since it's effectively making an authorization decision for an AFS subsystem, but that doesn't necessarily mean it's infeasible. > Should we do that? And warn administrators in the manpage that this > restricted access is not compatible with foreign users? Better options? I don't think refusing foreign users would kill this; iirc they have some other restrictions like you can't identify them as an SUser or stuff like that. But basing this off of krb5-specific information doesn't seem desirable; it may need to be reworked entirely for rxgk or any other security class. I'm not sure if we can avoid doing ptserver lookups in the vlserver forever... it seems like that would be required for having in-band delegated volume administration and things like that (unless we create our own separate authz database for such operations). But I'm just thinking aloud. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
