User without permission can add entity to group through autocomplete widget.

Thanks for opening this!

If this were a 1.0.0 release, this would be a security bug, so bumping to critical.

The existing test coverage is all bypassing group access, which was a good way to get basic tests going quickly, but allows bugs like this to exist. So that's definitely going to be part of fixing this -- adding test coverage that's dealing with group access, not bypassing it. ;)

Fleshed out remaining tasks.

Thanks again,
-Derek

Excellent, thanks for getting this started!

Tagging for tests (per the remaining tasks).

Note: it's possible to configure a drupalci.yml to apply a patch to group before running tests in here. So we could be testing both this and your patch upstream. This is an example from datetime_extras that needed to patch duration_field:

 build:
   assessment:
     validate_codebase:
      container_command:
        commands:
          - "cd ${SOURCE_DIR} && cd modules/contrib/duration_field && sudo -u www-data curl https://www.drupal.org/files/issues/2019-11-08/3093354-2.patch | patch -p1"
...

See https://www.drupal.org/drupalorg/docs/drupal-ci/customizing-drupalci-tes... for more.

Hrm, I can't seem to reproduce this. Not sure if the latest group releases have automatically fixed this, or what. Here's a test that according to the summary should fail, but it passes. A test user not in group-A3 is unable to use group-A3 in the autocomplete widget.

Maybe I misunderstand these directions:

Add the Group Autocomplete widget to a Group Content Enable entity. For a user with permission to create entity, add new and enter name of group they don't have permission to add content to in the auto complete. Save the entity.

In this test, groupTypeA has a member roll with the following group perms:

      'view group',
      'create group_node:article content',
      'create group_node:article entity',
      'create group_node:page content',
      'create group_node:page entity',
      'delete own group_node:article content',
      'delete own group_node:article entity',
      'delete own group_node:page content',
      'delete own group_node:page entity',
      'update own group_node:article content',
      'update own group_node:article entity',
      'update own group_node:page content',
      'update own group_node:page entity',
      'view group_node:article content',
      'view group_node:article entity',
      'view group_node:page content',
      'view group_node:page entity',

The testUser belongs to group-A1 and group-A2, but not group-A3.

The test is logged in as testUser, trying to access group-A3, and everything checks out fine. The user cannot see group-A3, so the form submit fails (as expected).

Can you provide more clarity on what the actual bug is here?

Thanks/sorry,
-Derek

Not sure if I'm addressing your question directly, but we stumbled across this issue with a build we're working on. Essentially, it seems like every group is available via the autocomplete widget, regardless of the user's membership. The Select List widget works as expected, only providing the groups the users is in for selection, so we just switched everything to select list and moved on but would love to get this working for autocomplete as the size of the dropdown grows the further we're into the build (more groups).

I know I tried and failed to reproduce this locally months ago. I believe you, but I'm curious: were you testing as a user with some kind of 'bypass access checks' perm or UID 1? It's extra weird that select works right but autocomplete does not -- that would suggest a code bug, not human error during testing.

Some day (inshallah!), my life will settle down a little bit and I'll have more time to work on this module again. ;)

Thanks/sorry,
-Derek

p.s. Re-reading this issue -- right, how can the test in #7 be passing if this is a bug? Doesn't that replicate the steps that are supposed to trigger the bug? That patch doesn't "fix" anything, it just adds more test coverage.

-- Comment deleted because it was inaccurate. --

I have not tried running the test, but I ran into this issue on a project today.

• Create a Group type and, within it, a Group Role that is allowed to add content to it as group content.
• Create One User and Two Groups, Group A and Group B.
• Add the User to Group A and Group B but with different access levels. In Group A, they have that privileged role and so can add group content, in Group B they do not.
• As that user, go to /node/add/{my_content_type} and, using the Autocomplete Group widget, type "Group." I can select both A and B. If I add both groups and save, the Group Content gets added to both groups even though I do not have permission to add group content to Group B.

With the patch from comment 4 and the Groups patch mentioned in comment 3, I can only select and add the content to Group A, which is the expected behaviour.

I'd like to tag stable 2.0.0 and 1.0.0 releases. But this bug is giving me pause. I'm going to try again to add automated test coverage for the autocomplete widget that either reveals the bug or proves it's no longer there (presumably, fixed upstream in Group somehow?).

Opened MRs for both 1.0.x and 2.0.x (so I can see all the possible group / core versions from both pipelines) with my patch from #7. As I understand it, that should fail if this bug exists.

However, upon further review, maybe #12 is pointing to the difference. In that scenario, the user is a member of the "forbidden" group, but their group role isn't supposed to let you add stuff to the group. I'll expand the test coverage in the MRs to try that case, too.

Phew! That was fun.

Indeed, I still can't reproduce the thing where someone without permission to view groups they don't belong to can do anything bad with the autocomplete widget.

However, I definitely was able to get the test to fail in the case where an "outsider" role has 'view group' permission. In this case, someone can view groups, but isn't supposed to be able to add content to those groups. The autocomplete widget shows them all the groups they have access to view, so they can select whatever groups they want. Then the widget (wrongly) lets them add content to those groups.

I pushed a fix to both branches. I'm not sure it's the best fix. 😅 Ideally, we'd alter the query for what results the autocomplete is returning to filter by groups the current user has permission to add stuff to. But frankly, I haven't been following upstream Group changes enough, all the flexible_permissions stuff, etc. I don't know The Right Way(tm) to tie into that situation anymore. So for right now, simply to stop the bleeding, I added a EntityGroupFieldSelection::validateReferenceableEntities() method (which is plumbing from the upstream EntityReferenceSelection/DefaultSelection world. The autocomplete widget sets the right things to trigger this to further validate the selection that not only does the group exist, but the given user has permission to add relationships to it.

The tests, which were all failing in this can-view-but-can't-add-stuff case (failing because the test user was able to add the content), are now all passing (because the test user is no longer able to add content to groups they can see but don't have the right permission to add group relationship entities).

#3163943: Allow GroupQueryAccessHandler to accept any permission as an operation would indeed make this better. 😅 I'll ping @kristiaanvde about it and try to get some input on that approach.

But probably for the purposes of a short-term fix that doesn't require any upstream changes, what I've got is Good Enough(tm) to actually close the bug. We can open a follow-up and add an @todo about making it more slick, once something like #3163943 is working in Group core.

Just realized the "fix" would be broken in the case of group memberships (users). We need to special-case the permission checks if ($entity_plugin_id == 'group_membership')...

But I'm done for tonight, I'll pick this up again tomorrow.

Fixed the 'administer members' case.
Also opened #3556732: [pp-1] Filter out groups where the user does not have permission to add content from the returned autocomplete choices and added @todo/@see comments.

Merged so I can tag stable releases. We can clean this up more at #3556732: [pp-1] Filter out groups where the user does not have permission to add content from the returned autocomplete choices.

FYI: https://www.drupal.org/project/entitygroupfield/releases/2.0.0-rc1 and https://www.drupal.org/project/entitygroupfield/releases/1.0.0-rc1 are both now out. Testing welcome. I'd like to put out the corresponding stable releases before the end of 2025, ideally before the end of November. 😅 Thanks!

However, when I try to crate blank node/report and link it via group field and click button Add to Group I get silent error. Not sure where to find more details, while drupal error log doesn't contain any.
When saving node I get: The referenced entity (group: gid) does not exist.
Seems this all started after this fix has been implemented.

Just to prove that Anonymous user can create node/add to group I successfully can do it via direct link group/gid/content/create/group_node:report.