Contrib.social

Prevent accidental lockouts on the Role settings page and clarify the corresponding description for its select box

Open on Drupal.org →
Created on 1 July 2022, almost 2 years ago
Updated 21 April 2023, about 1 year ago

Problem/Motivation

The following happened on the production site of one of the Drupal Dojo Austin attendees. Two persons persons were unable to get access to any of the admin menu items while someone else had a greatly truncated list of admin menu items. The debugging and finding the root cause took a day or two. During that time nothing else got done nor anyone could access the site. In the end it turned out that the attendee changed the administration role on admin/people/role-settings by accident to content editor. That caused that all permissions for the content editor role got checked and greyed out while all administrator role permissions got unchecked. I've illustrated the scenario in the attached video: https://www.drupal.org/files/issues/2022-07-01/lockout.mov → (*sorry for the long pageloads but the combination of a screen recording while docker is running is demanding for my old computer). The issues illustrated in the attached video are:

- If you have a user with the administrator and authenticated user role and you change the administrator role as this user from administrator to content editor you get forwarded to an Access denied page. You are completely locked out of the admin menu.
Let's assume the worst case scenario you have a site with a group of four admin accounts and one super admin account. The super admin is on vacation or on a business trip or something else happened to the person so that he or she is unavailable for several days or weeks. Now one of those four accounts changes the role in the Role settings by accident as happened above. The four admin users would be completely locked out. Or in case 📌 Add a container parameter that can remove the special behavior of UID#1 Fixed lands there wouldn't be any super admin account able to correct the oversight even and regain access would be even more complicated.

- The description of the select box on the Role settings page is incorrect and creates false expectations:
This role will be automatically assigned new permissions whenever a module is enabled. Changing this setting will not affect existing permissions.
The statement that changing this setting will not affect existing permissions applies to every role except the administrator role. Problem with the administrator role in the standard profile - on install it is set as the administration role and every checkbox is selected. If you change now the administrator role on the Role settings page the permissions of the administrator role get reset to its defaults. If you take a look at the default permissions assigned in the standard profile: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/profiles/sta... it is clear why after changing the administrator role on the role settings page all checkboxes are unchecked. Since the administrator role is the role that is assigned initially for the standard profile install and changed later on it is a potential source of confusion and problems.

Steps to reproduce

- Create a new user and assign the authenticated and administrator role (aside user #1)
- Log in with that new admin user
- Got to admin/people/role-settings
- Change the administrator role from administrator to content editor
- You will get an Access denied page and be locked out completely

I've checked in Drupal 9.4.1 and Drupal 10.0.x-dev. The problem applies to both versions.

Proposed resolution

- One option would be to add a confirmation dialogue asking the user if he or she is sure about the step and the possible consequences.
- Another level of safety would be to test if the user applying the change on the Roles settings page has still the permission administer roles and permissions in one of his/her roles. That way even if the user lacks permissions to see the admin menu and admin page it would be at least possible still to access the Role settings page:

That way the user would see immediately something is off and is still able to correct the mistake on his or her own.
- Depending on the changes applied the description underneath the select box on the Role settings page needs an adjustment.

Addendum: The issue was discovered and discussed during the Drupal Dojo in Austin over the course of two or three consecutive weeks. It would be good if someone could provide @cutehair and @rocketeerbkw an issue credit since both helped discovering and understanding this as well as the issue linked as a related issue.

📌 Task
Status

Active

Version

10.0 ✨

Component
User system  →

Last updated 1 day ago

Created by

🇩🇪Germany rkoller Nürnberg, Germany

Live updates comments and jobs are added and updated live.
  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 1 year ago →
    🇺🇸United States saxmeister

    I would definitely add that a best practice that has been adopted is the removal of user #1/admin as a way of preventing site hacks. So any checks would need to factor that in and not default to UID #1.

    One possible solution is:
    1. Place a warning above the drop-down box.
    2. Add an extra step to warn the user what they are doing.
    3. If the user is already Admin then continue to keep their user as Admin to at least allow the option of resetting this or they would otherwise be locked out and would have to depend on reimporting the database or reimporting site configuration to fix the issue.

    Also, adding a Drush command that would allow this value to be updated would help. A new command under the drush user commands would be ideal.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024