I’m starting to drill down into some more permissions stuff and in this case I’m using v8.5.6.
I notice that a Page Type I made (probably as admin way back when) I cannot edit the Output as another user that is in the Administrators group. I have a hunch I can probably find which system pages I need to change the Permissions on, but… when I go and analyse the admin user, I cannot from the Dashboard tell how they get their elevated access… They’re not a member of the administrator, or any group!
I don’t know if this is addressed in v9.x as for long winded reasons I can’t get to that for a while. But… to me this makes access control confusing and challenging to know what to expect. If I had to delete and remake that admin account, I can’t have confidence I will be able to make it with all the access it previously had! And from a security perspective that’s a problem.
I’ve pondered this as well, and wondered about certain rights even “administrators” don’t seem to have. Years ago in my mind at this point. The super user has ultimate control. If you do a group check on super user being an admin, they aren’t. The core does checks if the current user is the super user, or a member of other groups when doing permission checks. This being said, you can set a super user in the config by id, and that user becomes THE “super user”, so never a truly safe check for user id 1 when checking for super admin status…
The super admin is exempt from all permission checks. If you dig into the code, most checks say something like “if (super amin) then don’t bother to check any further”. The reason being that otherwise it would be possible to permission a site out of access with no way to get back in, even as super admin.
In most systems I build, I add myself as a second member. The first one is the Superuser that gets created by default but then I also add myself as a separate user as part of the Administrators group. That way I can experience life as a ‘mere mortal’ Administrator. Once the system is handed to a client, I’ll usually remove my ‘real’ self from the membership.
@andrew any chance we can get you to chime in on this topic?
From a security perspective this is actually a problem, as the access cannot reliably be fully audited. Plus I see no means to provide/revoke said access to whomever user I want.
I certainly do appreciate the fail-safe aspect of this design, but this also leads to usability problems (who has rights to edit this page template? I can’t tell!). As it stands, the way this is done really is not a good practice. We really need something better, but I’m not sure what just yet. Hoping Andrew can chime in and we can build upon this.
I really think this should be a continued discussion, and the devs should be included here. I don’t know their side of this, or if any efforts are underway to change this behaviour. But as it stands to me this isn’t ideal at all.
@BloodyIron - if you’re talking about editing the output of a page type default then yes that’s historically the super user’s domain, mainly because you can really mess up a site pretty easily.
But if you think it should be a modular permission to edit the page type default output on various templates (I think that’s what you’re saying here) that could be a good feature request:
It’s more that I think every single class and type of access should be completely visible to any “root” admin on any tool (in this case Concrete CMS). Such that said access can be delegated, or not, in useful ways.
I appreciate the concern for how such things can break, and I’m not advocating for the permission being distributed “willy nilly” so to say. But as I currently see it, the permission itself is “invisible” without deep digging, and cannot be granted to other users/groups at all. And that is really the bigger issue, because it seems to me perfectly reasonable for certain users/groups to want/need this permission, and the ecosystem should have a mechanism to grant/revoke it, just like all other permissions. The permission ecosystem within Concrete CMS is a HUGE value to the things I care about, and it’s one item on an endless list of what keeps me with Concrete CMS, hehe.
I take your subtle hint, and I’ll create the FR on the repo shortly. I do appreciate your insights into this, as there’s plenty you’ve seen and done, that I haven’t (yet?). So thanks for your participation!
I appreciate you opening the issue! And I agree - I think there are some good times to revisit permissions schema.
I’m in agreement with you that it’s best to expose these permissions entities so they can be configured and cascaded wherever possible, so I think it’s a good thing to get that feature request in there
I do appreciate your insights into this, as there’s plenty you’ve seen and done, that I haven’t (yet?). So thanks for your participation! 
No worries! Would you mind posting in the GitHub thread showing your support please?