- 🇫🇷France prudloff Lille
I see this was committed.
Is something still needed here or can we close this?
The security team now has a FAQ → that mentions the following:
Another case where no security announcement is required is when an exploit requires one of the following permissions:
- Administer filters
- Administer users
- Administer permissions
- Administer content types
- Administer site configuration
In general, every permission that in itself already enables site-takeover.
Why do we have 5 different "super-admin" permissions? Clearly not every Drupal site admin on Earth understands that all 5 of those are effectively "own the site" perms. If having access to any of them gives you powers to accomplish all of them, why pretend there's any priv separation among them at all? Why not a single "super-user" permission? Something like:
"Administer as superuser" ?
Wouldn't that be a lot clearer for people trying to configure permissions on their sites? Wouldn't that remove the illusion that any of these permissions are actually distinct that could safely be granted to a non-super-admin on their own?
Active
11.0 🔥
base system
Makes Drupal easier to use. Preferred over UX, D7UX, etc.
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I see this was committed.
Is something still needed here or can we close this?