Module forbidding the 'edit' operation on the User entity's 'pass' field would prevent editing security-sensitive base fields

The failing test-only patch that proves this is a bug, lifted from #2824851-199: EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior.

To make this work, we'll need to ensure that the User entity's pass field does get set even when editing it is not allowed.

#3 depends on #2824851: EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior having landed first.

#2 will have failed at

    // DX: 422 when changing email while providing a wrong password.
    $response = $this->request('PATCH', $url, $request_options);
    $this->assertResourceErrorResponse(422, "Unprocessable Entity: validation failed.\nmail: Your current password is missing or incorrect; it's required to change the Email.\n", $response, FALSE, FALSE, FALSE, FALSE);

With #3, the failure will have shifted down a few dozen lines in the test scenario, to:

    // DX: 422 when changing password without providing the current password.
    $response = $this->request('PATCH', $url, $request_options);
    $this->assertResourceErrorResponse(422, "Unprocessable Entity: validation failed.\npass: Your current password is missing or incorrect; it's required to change the Password.\n", $response, FALSE, FALSE, FALSE, FALSE);

    $normalization['pass'][0]['existing'] = $this->account->pass_raw;
    $request_options[RequestOptions::BODY] = $this->serializer->encode($normalization, static::$format);

IOW: thanks to #3, at least // Test case 1: changing email. can be completed successfully. But // Test case 2: changing password. fails.

Why?

Because \Drupal\rest\Plugin\rest\resource\EntityResource::patch() calls \Drupal\rest\Plugin\rest\resource\EntityResourceValidationTrait::validate(), which calls $violations->filterByFieldAccess();… and since the pass field cannot be edited according to the field access checking, there also shouldn't be any validation errors for it.

But of course, #3 does allow the pass field to be set (although only to be able to check that the correct password was provided when modifying security-sensitive fields: mail, name and pass) … which is how you're effectively able to bypass security, thanks to the patch in #3 (not in HEAD).

If you want to confirm #5 yourself, add this debug output:

diff --git a/core/modules/rest/src/Plugin/rest/resource/EntityResourceValidationTrait.php b/core/modules/rest/src/Plugin/rest/resource/EntityResourceValidationTrait.php
index 09b4b64..edd29e1 100644
--- a/core/modules/rest/src/Plugin/rest/resource/EntityResourceValidationTrait.php
+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResourceValidationTrait.php
@@ -29,10 +29,14 @@ protected function validate(EntityInterface $entity) {
     }
     $violations = $entity->validate();
 
+    var_dump($violations->getFieldNames());
+
     // Remove violations of inaccessible fields as they cannot stem from our
     // changes.
     $violations->filterByFieldAccess();
 
+    var_dump($violations->getFieldNames());
+
     if ($violations->count() > 0) {
       $message = "Unprocessable Entity: validation failed.\n";
       foreach ($violations as $violation) {