[19525] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Fwd: Question about aname_do_match behavior on invalid patten

daemon@ATHENA.MIT.EDU (Eric Diven)
Wed Jan 25 10:25:11 2017

MIME-Version: 1.0
In-Reply-To: <CAAWz=6DEVKCY46-ZUZb0Z0T2QpUc40VdYO+ZgXL6muAtYtoukw@mail.gmail.com>
From: Eric Diven <ebd2.github@gmail.com>
Date: Wed, 25 Jan 2017 10:25:01 -0500
Message-ID: <CAAWz=6CcSQV2K+frEJammWJz6buVhpzdedh4YQnFJOsL7dj3tA@mail.gmail.com>
To: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

Apologies, I did that thing :-/

On Tue, Jan 24, 2017 at 11:43 AM, Greg Hudson <ghudson@mit.edu> wrote:
>
> On 01/23/2017 06:15 PM, Eric Diven wrote:
> > When regcomp returns a non-zero result, aname_do_match returns
> > KRB5_LNAME_NOTRANS. This seems like odd behavior for what appears to be
an
> > error in the krb5.conf file. Can somebody please explain the rationale
> > behind this?
>
> I don't think anyone can speak to the rationale behind this behavior as
> it's very old.  Although I reorganized the code significantly in 1.12
> when I added the localauth pluggable interface, that behavior dates back
> to 1.0.  If you look at the an_to_ln.c code from back then, the behavior
> could be explained by a kind of laziness; the code looks like "if
> (!regcomp(...) && !regexec(...))" and similar for other regexp types.

Thanks for the explanation. I wanted to make sure I wasn't missing
something subtle (or blindingly obvious ;-) )

> I agree that it would be more helpful to KRB5_CONFIG_BADFORMAT, with an
> extended error message explaining that the regexp is bad.  There is some
> risk of breaking people's kind-of-working config files if we make that
> change, but the risk might be acceptable.

My reading of the code is that invalid rules essentially become a no-op
since the auth to local code will keep trying rules. I'm going to follow
your example and if other folks on our end insist on throwing a config
error, the resolution step would be to just remove the offending rule.

Thanks again,

Eric
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post