-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resolve user and groups in nested groups first before filtering the results #14464
Conversation
1e00d56
to
09357b8
Compare
|
Merged. |
Currently groupsMatchFilter is called before nested groups are resolved. This basicly breaks this feature since it is not possible to inherit membership in a group from another group. Minimal example: Group filter: (&(objectClass=group),(cn=nextcloud)) Nested groups: enabled cn=nextcloud,ou=Nextcloud,ou=groups,dn=company,dn=local objectClass: group cn=IT,ou=groups,dn=company,dn=local objectClass: group memberOf: cn=nextcloud,ou=Nextcloud,ou=groups,dn=company,dn=local cn=John Doe,ou=users,dn=company,dn=local objectClass: person memberOf: cn=IT,ou=groups,dn=company,dn=local Since 'cn=IT,ou=groups,dn=company,dn=local' doesn't match the group filter, John wouldn't be a member of group 'nextcloud'. This patch fixes this by filtering the groups after all nested groups have been collected. If nested groups is disabled the result will be the same as without this patch. Signed-off-by: Roland Tapken <[email protected]>
The previous patch fixed the problem only for one level of indirection because groupsMatchFilter() had been applied on each recursive call (and thus there would be no second level if the first level fails the check). This new implementation replaces the recursive call with a stack that iterates all nested groups before filtering with groupsMatchFilter(). Signed-off-by: Roland Tapken <[email protected]>
Nested groups are now cached in a CappedMemoryCache object to reduce queries to the LDAP backend. Signed-off-by: Roland Tapken <[email protected]>
…anymore. Signed-off-by: Roland Tapken <[email protected]>
and also consolidate logic in one method Signed-off-by: Arthur Schiwon <[email protected]>
14315cc
to
ca963fa
Compare
…more Signed-off-by: Arthur Schiwon <[email protected]>
ca963fa
to
dfc7007
Compare
Signed-off-by: Arthur Schiwon <[email protected]>
Signed-off-by: Arthur Schiwon <[email protected]>
🤖 beep boop beep 🤖 Here are the logs for the failed build: Status of 16802: failureTESTS=acceptance, TESTS-ACCEPTANCE=app-files
Show full log
TESTS=acceptance, TESTS-ACCEPTANCE=app-files-sharing
Show full log
TESTS=acceptance, TESTS-ACCEPTANCE=app-files-sharing-link
Show full log
|
failing tests are unrelated |
/backport to stable15 |
/backport to stable14 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐘, but 👍 because there are tests 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. And tests so lets 🎢
The backport to stable15 failed. Please do this backport manually. |
The backport to stable14 failed. Please do this backport manually. |
Continuation of #8227
As described by @Cybso in #8227 (comment), when users were not part directly of a whitelisted group, but of an excluded subgroup, they would wrongly not appear as member of the top group. While the excluded groups should not be used and shown in Nextcloud, their users still qualify to be associated with the top group. Users are only subject to user filter and user base restrictions.
We have had three places covering the nesting logic aka recursive lookup. I continued @Cybso approach to cover all cases, and consolidating it into one. Plus, integration tests make sure that all desired users are being found :)