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

[Gergely Risko]

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

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

But this is very not expert topic anymore.  It's possible to setup a
kerberos realm with your own domain name in like 30 minutes on a $5
virtual machine with an IPv4 address.

Oh, no, I see what you mean.  My own fake kerberos realm won't be good
enough, because it doesn't have the cross realm ticket granting tickets
with the target realm, right?

We're talking about users who has a valid kerberos ticket with our home
realm or with another realm that we have cross kerberos relationships
with, but who has no entry in ptdb or the entry can't be created because
there is no automatic afs foreign access for that realm.

It doesn't sound that bad now that I understand it.  This certainly
needs to be mentioned in the manual page, but before the option it was
wide open.  So this is definitely better already and not very easy to
fake.  For a moment I thought that any kerberos ticket would do, but now
I remember that's not how kerberos works.  Sorry for the
misunderstanding.

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

Yeah, I understand that this would be useful for the future too, but
creating an ubik client for vlserver, volserver (and then I guess we
want to share it with fileserver) is a refactoring that seems to be a
bit expensive for this project.

Gergely