If a module defines dynamic permissions, and at some point some of those permissions are removed by the providing module, the permissions persist in the active configuration. This is bad because not only does it leave cruft in the configuration system, but if the dynamic permissions are recreated later, they pick up the former values rather than being initialized from scratch, which could be a security risk.
Note that I reproduced this with the Scheduled Updates module, but I bet it would work with any module providing dynamic permissions. To reproduce:
- Install the scheduled updates module and create a new update type (or just install Lightning, which creates a bunch by default)
- Set the permissions for the update type at admin/people/permissions
- Delete the update type that you just created
- Export configuration for the site
Expected result:
There are no permissions related to the deleted update type in the config export.
Actual result:
The permissions related to the deleted update type persist in the configuration.
Similarly, after the last step, you can recreate the original update type. The expected behavior would be for it to have no associated permissions. The actual behavior is that it picks up the original permissions.
Comments
Comment #9
quietone commentedThis is a duplicate of an earlier issue, #2571235: [regression] Roles should depend on objects that are building the granted permissions which was fixed in Drupal 9.3.x.
Closing this as a duplicate.