Problem/Motivation

This issue has been cleared by the Drupal Security Team to be discussed in public.

Currently, it is possible for $entity->access('update') to return TRUE even when $entity->access('view') returns FALSE. An example is if someone has permission to "Article: Edit own content" and does not have permission to "View own unpublished content", then they are allowed to update an unpublished article that they cannot view.

Several potential problems arise from this:

  • Does it make sense conceptually to be able to update something that you cannot view?
  • Even if it makes sense conceptually, most edit forms show you the current field values of what you're editing. At which point, you're basically viewing whatever it is that someone decided to not give you permission to view.

Steps to reproduce

Proposed resolution

  • Option 1: change nothing, consider this "by design".
  • Option 2: change edit forms to require view access in addition to update access, but continue to allow non-form updates without view access, if those ways of updating don't disclose current values.
  • Option 3: continue to allow updates via edit forms, even without view access, but in those cases change the forms to not disclose current values.
  • Option 4: don't return TRUE from $entity->access('update') if $entity->access('view') isn't also TRUE.

Remaining tasks

Decide on one of the options, or come up with additional options.

User interface changes

API changes

Data model changes

Release notes snippet

Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

#1368610: It is confusing why creating a node requires users to have permission to "view published content" is related in an almost inverse way. It highlights how our current behavior of "view published content" controlling all access, not only view access, is confusing.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.