Support Broken Role Inheritance in the Site Pages Library (fix it because it's broken)
Premier Support has indicated that the Site Pages Library no longer supports broken role inheritance, minimally, for modern rendering site collections. This means the common pattern used to secure and limit editing content to separate organizational roles is no longer supported.
As an example:
create a modern Communications Site (SITEPAGEPUBLISHING#0)
add a non-administrative user to the default Visitor's group
go to the Site Pages Library Settings
- under Advanced Settings, select "Yes" to "Make 'New Folder' command available?" and save changes
- Under Permissions for this Document Library, break role inheritance and directly grant Full Control to the non-administrative account from above (use Check Permissions to separately verify/validate the non-administrative account has Full Control)
Log into the site collection under the non-administrative account, navigate to the Site Pages Library and change the view to "All Pages", click the "New" command to expand it, and select "Site Page" - You will receive an access denied message despite having Full Control over that library.
Go back to the Site Pages Library and try to create a folder - Folder creation succeeds, oddly enough
As a site collection administrator, add that non-administrative account to the default site owner's group.
Log back in as the non-administrator account and try to create a site page - it will succeed
As a site collection administrator, go back to the permissions for the Site Pages library and REMOVE all permissions for the default Site Owners group and verify through Check Permissions the Site Owners group has no rights to the Site Pages Library
Log back in as the non-administrative account, and try to create a site page. Despite being in the default Site Owners group AND having no permissions on the Site Pages library, the page is created
Investigating this, it appears that permissions are checked at the site level for site page creation rather than at the local scope and will incorrectly determine permissions, but the security determination is inconsistent given the existence of the command. Instead of checking permissions at the site level, permissions SHOULD be consistently checked, as it has been for years and continues to be done through classic rendering, at the current security scope.
Again, this was raised to Premier Support as a defect and after consulting the the Office Team, the decision was securing the Site Pages library by breaking role inheritance is NO LONGER SUPPORTED (despite being able to do exactly that through the UI) and, apparently, will be updating the official documentation to indicate such.
So, the recommendation is to implement security under modern rendering (so far it looks like it's only the Site Pages library under modern rendering) to have consistent behavior and support broken role inheritance like classic rendering has historically done.