You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@kudu.apache.org by "Todd Lipcon (Code Review)" <ge...@cloudera.org> on 2017/08/01 17:57:40 UTC

[kudu-CR] KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA

Hello Alexey Serbin,

I'd like you to do a code review.  Please visit

    http://gerrit.cloudera.org:8080/7551

to review the following change.

Change subject: KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA
......................................................................

KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA

FreeIPA is a piece of software that automates and simplifies management
of MIT krb5, SSSD, some LDAP service, etc. FreeIPA configures a
localauth plugin[1] in krb5.conf to map Kerberos principals to local
usernames. In this configuration, Kudu daemons were failing to start up
due to failure to map their own service principals back to a username.
This is due to a number of issues:

1) FreeIPA distinguishes between service principals and user principals
and doesn't store a 'uid' field in LDAP for service principals. Thus,
when 'sssd' tries to map a service principal to a local unix user, it
determines that there is no such user (ie getpwnam() fails). This is by
design, best I can tell.

2) sssd's implementation of krb5_auth_to_localname[1] uses getpwnam to try
to map the kerberos principal to the local username. Because of the
above, it fails for service principals.

3) Prior to el7.3, ssd configures krb5 with 'enable_only = sssd' in the
localauth plugin section. This means that if sssd fails to perform the
mapping, it does not fall back to other mappings defined in krb5.conf
(eg explicitly defined auth_to_local rules). See [2]

4) Even after 7.3, there is an additional bug in sssd which I just
filed[3], which causes the fallback to still not work. Because of this,
we're getting the KRB5_PLUGIN_NO_HANDLE error code back up at the Kudu
layer.

We already have our own fallback case for KRB5_LNAME_NO_TRANS, and it
seems like we should just be handling PLUGIN_NO_HANDLE in the same way
to workaround the above behavior.

I tested this patch on a FreeIPA-configured system on el6.7. I was able
to successfully start a master with a FreeIPA-provided keytab and
authentication required, and use 'kudu table list' to authenticate to
it.

[1] https://github.com/SSSD/sssd/blob/master/src/krb5_plugin/sssd_krb5_localauth_plugin.c
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1297462
[3] https://pagure.io/SSSD/sssd/issue/3459

Change-Id: I7bc13b33053a73784350c9d30a3796a96d318c04
---
M src/kudu/security/init.cc
1 file changed, 5 insertions(+), 1 deletion(-)


  git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/51/7551/1
-- 
To view, visit http://gerrit.cloudera.org:8080/7551
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I7bc13b33053a73784350c9d30a3796a96d318c04
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <to...@apache.org>
Gerrit-Reviewer: Alexey Serbin <as...@cloudera.com>

[kudu-CR] KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA

Posted by "Alexey Serbin (Code Review)" <ge...@cloudera.org>.
Alexey Serbin has posted comments on this change.

Change subject: KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA
......................................................................


Patch Set 1: Code-Review+2

-- 
To view, visit http://gerrit.cloudera.org:8080/7551
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I7bc13b33053a73784350c9d30a3796a96d318c04
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <to...@apache.org>
Gerrit-Reviewer: Alexey Serbin <as...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-HasComments: No

[kudu-CR] KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA

Posted by "Todd Lipcon (Code Review)" <ge...@cloudera.org>.
Todd Lipcon has submitted this change and it was merged.

Change subject: KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA
......................................................................


KUDU-2087. Fix failure to map Kerberos principal to username with FreeIPA

FreeIPA is a piece of software that automates and simplifies management
of MIT krb5, SSSD, some LDAP service, etc. FreeIPA configures a
localauth plugin[1] in krb5.conf to map Kerberos principals to local
usernames. In this configuration, Kudu daemons were failing to start up
due to failure to map their own service principals back to a username.
This is due to a number of issues:

1) FreeIPA distinguishes between service principals and user principals
and doesn't store a 'uid' field in LDAP for service principals. Thus,
when 'sssd' tries to map a service principal to a local unix user, it
determines that there is no such user (ie getpwnam() fails). This is by
design, best I can tell.

2) sssd's implementation of krb5_auth_to_localname[1] uses getpwnam to try
to map the kerberos principal to the local username. Because of the
above, it fails for service principals.

3) Prior to el7.3, ssd configures krb5 with 'enable_only = sssd' in the
localauth plugin section. This means that if sssd fails to perform the
mapping, it does not fall back to other mappings defined in krb5.conf
(eg explicitly defined auth_to_local rules). See [2]

4) Even after 7.3, there is an additional bug in sssd which I just
filed[3], which causes the fallback to still not work. Because of this,
we're getting the KRB5_PLUGIN_NO_HANDLE error code back up at the Kudu
layer.

We already have our own fallback case for KRB5_LNAME_NO_TRANS, and it
seems like we should just be handling PLUGIN_NO_HANDLE in the same way
to workaround the above behavior.

I tested this patch on a FreeIPA-configured system on el6.7. I was able
to successfully start a master with a FreeIPA-provided keytab and
authentication required, and use 'kudu table list' to authenticate to
it.

[1] https://github.com/SSSD/sssd/blob/master/src/krb5_plugin/sssd_krb5_localauth_plugin.c
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1297462
[3] https://pagure.io/SSSD/sssd/issue/3459

Change-Id: I7bc13b33053a73784350c9d30a3796a96d318c04
Reviewed-on: http://gerrit.cloudera.org:8080/7551
Tested-by: Kudu Jenkins
Reviewed-by: Alexey Serbin <as...@cloudera.com>
---
M src/kudu/security/init.cc
1 file changed, 5 insertions(+), 1 deletion(-)

Approvals:
  Alexey Serbin: Looks good to me, approved
  Kudu Jenkins: Verified



-- 
To view, visit http://gerrit.cloudera.org:8080/7551
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I7bc13b33053a73784350c9d30a3796a96d318c04
Gerrit-PatchSet: 2
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <to...@apache.org>
Gerrit-Reviewer: Alexey Serbin <as...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>