See parent issue #3200985: [meta] Fix undesirable access checking on entity query usages for context and test coverage policy.
Drupal provides validation to enforce that the value of a field is unique among all entities of the entity type. This validation operates by querying existing entities to see if any of them already have the value that needs to be unique. This querying should find all entities, including ones that are not accessible to the current user.
Fixes needed:
core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/UniqueFieldValueValidator.php validate
core/modules/migrate/src/Plugin/migrate/process/MakeUniqueEntityField.php exists
This is a critical because it may compromise data integrity.
Issue fork drupal-3202125
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
jonathanshawComment #4
jonathanshawComment #5
jonathanshawKernel test coverage for the migrate bug would be obviously desirable, but there currently is none for this porcess plugin, I can't provide it, and I'm not sure it's important enough to hold up the wider issue tree.
Comment #6
jonathanshawLet's make #3171047: Entity query in UniqueFieldValueValidator must not use access checking into a follow-up.
Comment #7
jonathanshawBerdir pointed out in #3171047: Entity query in UniqueFieldValueValidator must not use access checking:
In order to unblock the parent issue, I suggest we make the bug explicit by adding accessCheck(TRUE) and a @todo linking to the other issue for changing it to FALSE.
Comment #8
jonathanshawSo to recap, there's 2 bugs here:
- core/modules/migrate/src/Plugin/migrate/process/MakeUniqueEntityField.php exists is fixable and also involves a simple tweak to its unit tests
- core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/UniqueFieldValueValidator.php is hard for the reasons discussed in #3171047: Entity query in UniqueFieldValueValidator must not use access checking and I'm suggesting we add an explicit accessCheck to unblock the parent issue, but make it TRUE to preserve the buggy existing behavior for now.
Comment #9
jonathanshawIf we're not actually working on the main bug here, just the unblocking, then it's only major.
Comment #10
BerdirHm. I'm not sure if I'm saying it is a hard blocker. Just that we need to consider the implications and decide if that is acceptable, which might need a release/framework manager decision or so? Wasn't very clear, sorry.
One idea would be to add a setting to be able to control it if someone wants that behavior for some weird reason. Combined with a release note/change record that says, we now no longer do access checks, which might result in some edge cases now. If you for some reason want to keep the existing behavior, change it to ->addValidationConstraint('UniqueThing', ['access_check' => TRUE]) (not sure if that's the exact syntax, but you get the idea).
Comment #11
catchI think adding accessCheck(TRUE), then opening a critical bug to fix it properly, makes sense to unblock the parent issue.
I cant really see a way that the current behaviour would be relied upon consciously, but I can definitely see us exposing some data integrity issue by fixing it.
Comment #12
jonathanshawI've made #3171047: Entity query in UniqueFieldValueValidator must not use access checking the critical fix. The MR here is ready for review on the lines of #8 & #11.
Comment #13
longwaveRTBC based on #11, in the difficult case this is just confirming the existing behaviour and leaving any possible change to it to the followup.
The migrate process plugin is more straightforward and this just shouldn't check access at all.
Comment #16
catchCommitted/pushed to 9.2.x and cherry-picked to 9.1.x, thanks!