Ashwani Raina has posted comments on this change. ( http://gerrit.cloudera.org:8080/23191 )
Change subject: KUDU-3676: Add support for Hadoop auth to local rule mapping ...................................................................... Patch Set 1: > > (8 comments) > > > > Thank you for adding this support. > > > > I had a cursory look. > > With my limited knowledge about hadoop auth mapping, I have a few > > questions. Apart from those, there are a few nits. > > I'll make sure to fix all the stylistic, formatting, and structure > changes. It's always good to ensure consistency where possible. > > The hadoop auth to local mapping is similar to mit kerberos > mapping, with a few minor differences, like the \L flag to > lowercase the output, or the 'hadoop' rule mechanism that prevents > '@' or '/' from appearing in the shortened principal output (not > the case for the 'mit' rule evaluation). > > There isn't any reason that multiple principals couldn't map to the > same shortened principal. > > For instance, the following rules are perfectly valid, even though > they map to the same output: > > RULE[1:$1@$0]([email protected])s/.+/kudu/ > RULE[2:$1@$0]([email protected])s/@.*// > RULE[2:$1@$0]([email protected])s/.+/KUDU/L > > All three of these rules resolve to a lowercase 'kudu'. > > This is perfectly valid and expected behaviour and entirely in the > hands of whoever writes the rules. There are a few places where my > implementation is a bit of a superset over Hadoop's auth to local > mapping, matching more closely with mit kerberos (eg an arbitrary > number of fields in the principal rather than exactly 3 fields), > but that won't break anything here. That was mostly implemented in > case Hadoop changed how that was handled in the future. > > As for the Default rule: > > This is an excerpt from > hadoop/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/util/KerberosName.java, > which is where the rule handling is implemented: > > String apply(String[] params, String ruleMechanism) throws > IOException { > String result = null; > if (isDefault) { > if (getDefaultRealm().equals(params[0])) { > result = params[1]; > } > ... > > where isDefault is true by default and set to false if some non > DEFAULT rule is parsed, params[0] is the realm, and params[1] is > the first part of the principal that matches this rule. > > So if a principal matches the default realm, without matching a > previous rule, we return the first part of the principal (mostly) > unconditionally, except for the potential '@' and '/' exclusion. > This differs a bit from MIT Kerberos where there's an extra check > to ensure the principal has exactly one or two parts when applying > the DEFAULT rule, and the second part of the principal must also > match the default realm (eg kudu/[email protected]). This > behaviour for MIT Kerberos can be found in 'krb5/src/lib/krb5/os/localauth.c' > in the ?an2ln_default function. > > In terms of security, Kerberos is still handling the actual > validation of clients. All that's happening here is that we skip > using Kerberos auth to local rules and instead apply the mapping > using a selected core-site.xml file. > > I do have a question about using std::regex: is it fine to use it > as I have here? The linter, when I ran it through Jenkins, > suggested I consider using posix regexes instead due to Redhat 7. > Is this important for Kudu? I see that Redhat 7 is still in the > list of supported operating systems for Kudu 1.18.x, but is it > necessary to take Redhat 7 libstdc++ into account for Kudu since it > gets built with a newer version of clang? Thank you for the detailed summary. I guess the lint check was added to detect the issue early on to avoid unexpected crashes due to broken std::regex implementation in older versions of libstd++ if a kudu binary is linked to such version. Check this commit: https://github.com/apache/kudu/commit/588416694c0543f33d3287f7d8547875a8adf51d This has more information on implementation status. -- To view, visit http://gerrit.cloudera.org:8080/23191 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I0e99639248fce01b9af0778074ecf6aa43660742 Gerrit-Change-Number: 23191 Gerrit-PatchSet: 1 Gerrit-Owner: Jeffrey Smith <[email protected]> Gerrit-Reviewer: Ashwani Raina <[email protected]> Gerrit-Reviewer: Jeffrey Smith <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Comment-Date: Thu, 21 Aug 2025 16:45:36 +0000 Gerrit-HasComments: No
