Question about aname_do_match behavior on invalid patten

[Eric Diven]

I'm porting the localauth_rule code to java for the Presto database
project, and I was curious about the design decision behind
aname_do_match's behavior when a rule contains an invalid pattern.

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?

The code I've written follows the behavior in Kerberos 5 1.15, but I'd like
to be sure I understand what I'm porting so I don't do something wrong.

I have searched the bug tracker and the mailing list archives, and I
haven't found any references to aname_do_match.

Thanks,

Eric

My code (in draft form) here: https://github.com/ebd2/presto/pull/3
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Eric Diven]

Incidentally, this is consistent with aname_replacer(); do_replacement()
returns KRB5_LNAME_NOTRANS when regcomp() returns a non-zero result as
well. I suppose I have the same question about the behavior there as well.

Thanks,

Eric

Post by Eric Diven
I'm porting the localauth_rule code to java for the Presto database
project, and I was curious about the design decision behind
aname_do_match's behavior when a rule contains an invalid pattern.
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?
The code I've written follows the behavior in Kerberos 5 1.15, but I'd
like to be sure I understand what I'm porting so I don't do something wrong.
I have searched the bug tracker and the mailing list archives, and I
haven't found any references to aname_do_match.
Thanks,
Eric
My code (in draft form) here: https://github.com/ebd2/presto/pull/3

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

[Greg Hudson]

Post by Eric Diven
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.

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.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Eric Diven]

Apologies, I did that thing :-/

Post by Greg Hudson

Post by Eric Diven
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 ;-) )

Post by Greg Hudson
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev