[
https://issues.apache.org/jira/browse/NIFIREG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299391#comment-16299391
]
Kevin Doran commented on NIFIREG-75:
------------------------------------
it looks like during group creation, FIleUserGroupProvider check that all the
users in the Group exist prior to creating the group, but only using the users
managed by FileUserGroupProvider, which fails. During group update,
FileGroupProvider does not validate the users, it blindly updates the user list
and persists it.
if you are using ldap, you probably want to manage groups in your central
directory
just to round this out - it is a similar issue when authorizing for a resource
that is causing the group permissions to not show up... the first step in
authorization is determining the current users and their groups. for a
composite user group provider, the first provider to recognize a user identity
is used, and the groups they know about are loaded. no other providers are
checked to see if they have a group containing the users, so from an
authorization perspective, we are checking policies for user nobel or groups
[chemists]. all the logic in authorization seems to be consistent with the
assumption that a user will only belong to groups in the userGroupProvider that
"owns" the user
> FileUserGroupProvider allows updating a group to contain unknown users
> ----------------------------------------------------------------------
>
> Key: NIFIREG-75
> URL: https://issues.apache.org/jira/browse/NIFIREG-75
> Project: NiFi Registry
> Issue Type: Bug
> Reporter: Kevin Doran
> Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> In FileUserGroupProvider, when a new group is created, all the users in the
> group are checked to ensure they are known to the FileUserGroupProvider prior
> to creating the group.
> However, when a group is updated, a similar check does not exist, allowing
> one to add invalid users to a group. This gets the server in a bad state with
> unexpected behavior surrounding authorization actions.
> Note that this logic was ported from NiFi, so NiFi should probably be updated
> with the same fix after verifying this is the intended behavior (having the
> check on update).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
