[
https://issues.apache.org/jira/browse/HADOOP-13832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling updated HADOOP-13832:
-----------------------------------
Attachment: HADOOP-13832.branch-2.7.001.patch
Attaching a patch created against branch-2.7, which I'm using for testing. I
will follow up with a patch against trunk.
This adds a new FileBasedGroupsMapping implementation, which reads group
membership information from a local file. The group memberships are then
cached in-memory for efficiency. So one area to normalize here is the refresh
frequency of the file-based mappings vs. the configured cache time in
hadoop.security.groups.cache.secs.
I'd appreciate any thoughts on the approach or current implementation.
> Implement a file-based GroupMappingServiceProvider
> --------------------------------------------------
>
> Key: HADOOP-13832
> URL: https://issues.apache.org/jira/browse/HADOOP-13832
> Project: Hadoop Common
> Issue Type: New Feature
> Components: security
> Reporter: Gary Helmling
> Attachments: HADOOP-13832.branch-2.7.001.patch
>
>
> In can be useful to decouple Hadoop group membership resolution from OS-level
> group memberships, without having to depend on an external system like LDAP.
> I'd like to propose a file-based group mapping implementation, which will
> read group membership information from a configured file path on the local
> filesystem, reloading periodically for changes. For simplicity, it will use
> the same file format as /etc/group.
> I'm aware of the option for static mappings in core-site.xml, but maintaining
> these in an xml file is cumbersome and these are not reloadable. Having a
> built-in file-based implementation will also make this more usable in other
> systems relying on Hadoop security tooling, such as HBase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]