Why does Route access checking differ from Entity access checking?

Ditto with Group and some of these operations. Applying the patch is not recommended without very carefully checking your module configuration.

Solving this is far beyond me, but I've struggled with these inconsistencies and would love to see a solution.

I made a patch for the solution proposed in #27.
I think it's a good solution for BC and is easy to implement for everyone who needs it.

Then we can add a deprecation notice and switch for the Symfony access check in a future Drupal release maybe ?

Use $access_result->isForbidden() explicitly since Access::Neutral() is also not $access_result->isAllowed()

Patch #44 resolves the problem for me.

I just ran into this problem using Edit Media Modal → - users who have permission to edit the media object have AccessResultNeutral after the access checks are done, which leads to core failing the check instead of allowing it.

The test failures imply that a lot of core's permission logic does not return Forbidden but instead return Neutral, which the old logic took to mean "no" when it should have been "yes".

With #44 the /user/logout route redirects to /user, but for some reason it then redirects to /user/0 instead of /user/login, and then gets a 403 error. This seems to cause most of the test failures.

This issue highlights two major DX problems:
1. A lack of documentation around access logic, how it should be used and how modules should interpret it.
2. Limitations in core's access tests, which leads people to thinking that certain operations should work, when they don't.

The problem I ran into with edit_media_modal is a perfect example of this - the user has the "edit [media type]" permission, the contrib logic uses that permission to determine access, but the access check fails when the user should have the appropriate access.

From #42 it would seem #27 was not clear: I suggested _symfony_routing_access to indicate a route is using symfony/Security instead of Drupal's system. I did not suggest this flag to change the behavior of Drupal's system.

I also believe both #42 and #44 needs some consider whether whether generic modules changing route access would open security holes with them.

For small changes I think #14 was the only feasible one. But, of course, what do I know? This is just my thought.

For large changes you would need to bring in symfony/security.

Just to summarize the current situation in other words, hopefully not getting it wrong:

Route Access is allowed, if ALL access checks return AccessResult::allowed(). It’s denied if ANY access check does NOT return AccessResult::allowed().

Entity Access is allowed, if ANY access check returns AccessResult:allowed() and NO access check returns AccessResult::forbidden(). It’s denied if NO access check returns AccessResult::allowed() or ANY access check returns AccessResult::forbidden().

Re #49 Sounds about right. I also summarized it as such in #33

The patch in #44 allows anonymous users to edit menus (/admin/structure/menu/manage/*), so beware of that!