Add a "system" right to replace checks for SEC_inGroup('root')

[leegarner]

To help delegate site administration to other users/groups without confusing group membership, add a "system" right such as "system.root" to be used instead of checking for Root membership.

Example, I have a site with a group "Club Officers". As the administrator, I may not be an officer but as a member of Root I am included in the group listing of officers and other groups anyway. If my account could be removed from Root but granted the system.root privilege, then all root access would be available without being a member of every other site group.

There are other ways, such as looking for directly-assigned members for the group list, but it seems simpler to avoid the group inclusion of Root completely.

For instance:

--- a/private/system/classes/config.class.php
+++ b/private/system/classes/config.class.php
@@ -792,7 +792,7 @@ class config
         if(!array_key_exists($grp, $LANG_configsubgroups)) {
             $LANG_configsubgroups[$grp] = array();
         }
-        if (!SEC_inGroup('Root')) {
+        if (!SEC_hasRights('system.root')) {
             return config::_UI_perm_denied();
         }

[mark0263]

What if - we modified SEC_inGroup() whenever root is passed - we also check for system.root feature. This way, you get all root access without being a member of root. Otherwise, would probably have to hit all the code where SEC_inGroup('Root') is called.

[leegarner]

Sure, that would be great.

[leegarner]

The main thing I'd like to avoid is the automatic membership that Root memberrs have in all other groups. So the "right" wouldn't technically be necessary, but conceptually I'd think that Rights are better suited for feature access and Groups for content access.

[mark0263]

the other option is I can bite the bullet and build out permissions / rights for the features that check for root. Looks like:

• Admin Actions
• Clear Cache
• Configuration
• Database Admin
• Environment Check
• Logview
• SFS User Check
• Upgrade Check

So I could create a feature / right for each - actions.admin, cache.admin, config.admin, database.admin, env.admin, logview.admin, sfs.admin, upgrade.admin.

Then we have the ability to be a bit more granular on granting permissions to certain areas.

I did code the system.root and it works fine - with just that right, you get the items listed above.

[walterrowe]

I wonder how many sites would really grant those rights to that level of granularity?

[leegarner]

For now I think that's fine. I also have a feature class that I've worked on to add more management for features/rights. I think for the things that you mention a single "system.root" feature (or in group Root) is fine. I don't see very many site owners wanting to separate admin duties that granularly.

On Sun, Apr 4, 2021 at 6:00 PM Mark R. Evans @.***> wrote:

the other option is I can bite the bullet and build out permissions / rights for the features that check for root. Looks like:

• Admin Actions
• Clear Cache
• Configuration
• Database Admin
• Environment Check
• Logview
• SFS User Check
• Upgrade Check

So I could create a feature / right for each - actions.admin, cache.admin, config.admin, database.admin, env.admin, logview.admin, sfs.admin, upgrade.admin.

Then we have the ability to be a bit more granular on granting permissions to certain areas.

I did code the system.root and it works fine - with just that right, you get the items listed above.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/glFusion/glfusion/issues/383#issuecomment-813130583, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLFOLZNM5FFHB4WOZCK5TTHEDUXANCNFSM4PC3A3WA .

[leegarner]

LOL, Walter had the same thought while I was typing...

On Sun, Apr 4, 2021 at 6:27 PM Lee Garner @.***> wrote:

For now I think that's fine. I also have a feature class that I've worked on to add more management for features/rights. I think for the things that you mention a single "system.root" feature (or in group Root) is fine. I don't see very many site owners wanting to separate admin duties that granularly.

On Sun, Apr 4, 2021 at 6:00 PM Mark R. Evans @.***> wrote:

the other option is I can bite the bullet and build out permissions / rights for the features that check for root. Looks like:

• Admin Actions
• Clear Cache
• Configuration
• Database Admin
• Environment Check
• Logview
• SFS User Check
• Upgrade Check

So I could create a feature / right for each - actions.admin, cache.admin, config.admin, database.admin, env.admin, logview.admin, sfs.admin, upgrade.admin.

Then we have the ability to be a bit more granular on granting permissions to certain areas.

I did code the system.root and it works fine - with just that right, you get the items listed above.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/glFusion/glfusion/issues/383#issuecomment-813130583, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLFOLZNM5FFHB4WOZCK5TTHEDUXANCNFSM4PC3A3WA .

[mark0263]

system.root capability implemented with 3b81d5f4e683e1ceb76aed9964867e71234cced9