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.
So… what’s going on here then?
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.
Maybe I was incorrect about setting super user in config. I dug and was reminded that it’s a constant, SUPER_USER_ID…
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: