[jira] [Commented] (KUDU-2087) Failure to map principal to local username in FreeIPA-configured environment
[ https://issues.apache.org/jira/browse/KUDU-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108271#comment-16108271 ] Todd Lipcon commented on KUDU-2087: --- Based on some investigation, the problem is many-fold: 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 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 https://bugzilla.redhat.com/show_bug.cgi?id=1297462 4) Even after 7.3, there is an additional bug in sssd which I just filed, which causes the fallback to still not work. See https://pagure.io/SSSD/sssd/issue/3459 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. > Failure to map principal to local username in FreeIPA-configured environment > > > Key: KUDU-2087 > URL: https://issues.apache.org/jira/browse/KUDU-2087 > Project: Kudu > Issue Type: Bug > Components: security >Affects Versions: 1.3.1, 1.4.0 >Reporter: Todd Lipcon >Assignee: Todd Lipcon > > FreeIPA is a tool provided by Red Hat which helps operators configure and > manage an integrated LDAP + Kerberos environment (sort of a parallel of > Active Directory from what I can tell). In this environment, the local MIT > krb5 installation is configured to use the SSD 'localauth' plugin, which is > responsible for mapping principals to usernames by implementing the > krb5_auth_to_localname() API. > In this environment, Kudu fails to start with Kerberos enabled because the > krb5_auth_to_localname() API is returning KRB5_PLUGIN_NO_HANDLE when it tries > to map its own principal to a username. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KUDU-2085) Seek past last element of a prefix-encoded binary block may crash
Todd Lipcon created KUDU-2085: - Summary: Seek past last element of a prefix-encoded binary block may crash Key: KUDU-2085 URL: https://issues.apache.org/jira/browse/KUDU-2085 Project: Kudu Issue Type: Bug Components: cfile Affects Versions: 1.4.0, 1.3.1, 1.2.0, 1.1.0, 1.0.1 Reporter: Todd Lipcon Assignee: Todd Lipcon Priority: Critical Similar to KUDU-2049, the binary prefix block encoder has a bug when seeking past the end of the block (i.e to the offset past the last element). The bug only causes issues in very specific circumstances: - the number of elements in the block has to be a multiple of 16 (the "restart interval") -- this causes the code to interpret the "restart count" at the end of the block data as an offset instead of part of the footer. - this value, when interpreted as an offset, points to a piece of data in the block which, when interpreted as a varint, ends up large enough to point past the end of the block. This results in an error like: F0730 09:56:07.291882 124055 binary_prefix_block.cc:325] Check failed: _s.ok() Bad status: Corruption: Could not decode value length data at idx 32 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KUDU-2084) Improve to increase/decrease the number of maps for MR/YARN job on Kudu
[ https://issues.apache.org/jira/browse/KUDU-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107513#comment-16107513 ] Jean-Daniel Cryans commented on KUDU-2084: -- bq. Should we make improvement to let customer at lease able to decrease the mapper? Not just a single's vendors customers but also every Kudu users :) I think this could tie into our idea of having Scan Tokens that can be split into more chunks, something other frameworks can leverage too. [~danburkert], was there a jira for this? > Improve to increase/decrease the number of maps for MR/YARN job on Kudu > --- > > Key: KUDU-2084 > URL: https://issues.apache.org/jira/browse/KUDU-2084 > Project: Kudu > Issue Type: Improvement >Reporter: David Wang > > Right now, we can't increase/decrease the number of maps of MR/YARN job by > below logical. > https://github.com/cloudera/kudu/blob/branch-1.4.x/java/kudu-mapreduce/src/main/java/org/apache/kudu/mapreduce/KuduTableInputFormat.java#L137-L166 > Should we make improvement to let customer at lease able to decrease the > mapper? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
