Support Questions

Find answers, ask questions, and share your expertise

hbase/hadoop/hdfs LDAP groups with spaces

avatar
Contributor

So I've enabled cell level security.  Having an issue with spaces in groups retrieved from LDAP.  In our Cloudera 6.2.1 cluster the LDAP for HDFS is configured to retrieve the groups from our LDAP server.  That works fine.

 

But when I run hbase shell (kerberized with my kerberos ticket) any groups with spaces in the 'cn' are split into separate groups when I run the hbase shell 'whoami' command.  For example if my LDAP group is called 'my cool group' in hbase shell whoami it shows 3 separate groups... 'my' 'cool' and 'group'.  Unfortunately I can't change the group name to remove the spaces in LDAP.  Therefore if I created an hbase cell visibility set to a label that maps to this LDAP group I can't retrieve the cell.

 

hbase shell> whoami

...

Groups: 'anothergroupwithoutspaces', 'my', 'cool',' group'

 

add_label ['my_cool_label']

set_auth '@my\ cool\ group',''my_cool_label'] (you need backslashes to escape the space)

 

put 'myTable', 'cf1:cq1', 'myValue', { VISIBILITY => 'my_cool_label']

(can't see this cell)

 

From what I can see the only option is instead of using the group 'cn' value I need to add another field in that LDAP node and have the group name without spaces.

 

eg. cn_hadoop = my-cool-group

 

Or is there another option?

 

Richard

1 REPLY 1

avatar
Contributor

To followup...

 

Got this working today.  Turns out it was caused by this setting...

 

hadoop.security.group.mapping=org.apache.hadoop.security.ShellBasedUnixGroupsMapping

 

Apparently this does a...

 

bash -c groups

 

...for the user... which separates the groups by spaces.  When I changed to this implementation...

 

hadoop.security.group.mapping=org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback

 

... everything worked correctly.  Now hbase shell correctly lists the groups (even ones with spaces) and visibility labels works correctly.

 

That was a fun one... NOT!

 

Richard