[
https://issues.apache.org/jira/browse/HDFS-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Opell updated HDFS-8748:
------------------------------
Flags: Patch
> ACL permission check does not union groups to determine effective permissions
> -----------------------------------------------------------------------------
>
> Key: HDFS-8748
> URL: https://issues.apache.org/jira/browse/HDFS-8748
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: HDFS
> Affects Versions: 2.7.1
> Reporter: Scott Opell
> Labels: acl, permission
> Attachments: HDFS_8748.patch
>
>
> In the ACL permission checking routine, the implemented named group section
> does not match the design document.
> In the design document, its shown in the pseudo-code that if the requester is
> not the owner or a named user, then the applicable groups are unioned
> together to form effective permissions for the requester.
> Instead, the current implementation will search for the first group that
> grants access and will use that. It will not union the permissions together.
> Here is the design document's description of the desired behavior
> {quote}
> If the user is a member of the file's group or at least one group for which
> there is a
> named group entry in the ACL, then effective permissions are calculated from
> groups.
> This is the union of the file group permissions (if the user is a member of
> the file group)
> and all named group entries matching the user's groups. For example, consider
> a user
> that is a member of 2 groups: sales and execs. The user is not the file
> owner, and the
> ACL contains no named user entries. The ACL contains named group entries for
> both
> groups as follows: group:sales:r\-\-, group:execs:\-w\-. In this case,
> the user's effective
> permissions are rw-.
> {quote}
>
> ??https://issues.apache.org/jira/secure/attachment/12627729/HDFS-ACLs-Design-3.pdf
> page 10??
> The design document's algorithm matches that description:
> *Design Document Algorithm*
> {code:title=DesignDocument}
> if (user == fileOwner) {
> effectivePermissions = aclEntries.getOwnerPermissions()
> } else if (user ∈ aclEntries.getNamedUsers()) {
> effectivePermissions = aclEntries.getNamedUserPermissions(user)
> } else if (userGroupsInAcl != ∅) {
> effectivePermissions = ∅
> if (fileGroup ∈ userGroupsInAcl) {
> effectivePermissions = effectivePermissions ∪
> aclEntries.getGroupPermissions()
> }
> for ({group | group ∈ userGroupsInAcl}) {
> effectivePermissions = effectivePermissions ∪
> aclEntries.getNamedGroupPermissions(group)
> }
> } else {
> effectivePermissions = aclEntries.getOthersPermissions()
> }
> {code}
> ??https://issues.apache.org/jira/secure/attachment/12627729/HDFS-ACLs-Design-3.pdf
> page 9??
> The current implementation does NOT match the description.
> *Current Trunk*
> {code:title=FSPermissionChecker.java}
> // Use owner entry from permission bits if user is owner.
> if (getUser().equals(inode.getUserName())) {
> if (mode.getUserAction().implies(access)) {
> return;
> }
> foundMatch = true;
> }
> // Check named user and group entries if user was not denied by owner
> entry.
> if (!foundMatch) {
> for (int pos = 0, entry; pos < aclFeature.getEntriesSize(); pos++) {
> entry = aclFeature.getEntryAt(pos);
> if (AclEntryStatusFormat.getScope(entry) == AclEntryScope.DEFAULT) {
> break;
> }
> AclEntryType type = AclEntryStatusFormat.getType(entry);
> String name = AclEntryStatusFormat.getName(entry);
> if (type == AclEntryType.USER) {
> // Use named user entry with mask from permission bits applied if
> user
> // matches name.
> if (getUser().equals(name)) {
> FsAction masked = AclEntryStatusFormat.getPermission(entry).and(
> mode.getGroupAction());
> if (masked.implies(access)) {
> return;
> }
> foundMatch = true;
> break;
> }
> } else if (type == AclEntryType.GROUP) {
> // Use group entry (unnamed or named) with mask from permission bits
> // applied if user is a member and entry grants access. If user is
> a
> // member of multiple groups that have entries that grant access,
> then
> // it doesn't matter which is chosen, so exit early after first
> match.
> String group = name == null ? inode.getGroupName() : name;
> if (getGroups().contains(group)) {
> FsAction masked = AclEntryStatusFormat.getPermission(entry).and(
> mode.getGroupAction());
> if (masked.implies(access)) {
> return;
> }
> foundMatch = true;
> }
> }
> }
> }
> {code}
> As seen in the GROUP section, the permissions check will succeed if and only
> if a single group (either owning group or named group) has all of the
> requested permissions. The permissions check should instead succeed if the
> requested permissions can be obtained by unioning all of the groups
> permissions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)