Question on group inheritance

[shentino]

Noticed this feature in the announcement, but I would like some more information.  I think the announcement thread was locked, so I thought I'd ask here.

What is group inheritance?

And perhaps most quirky, is to know whether or not two groups can cyclicly inherit from each other, or if one group can inherit more than one group.

[shentino]

Um...did I post this in the wrong board?

[Smurfbutcher Bob]

At present, SMF uses an "aggregate" model:

- User belongs to several groups.
- User has no implicit rights.

Groups are walked, and all "allows" are collected. Same with Denials.
For a given right, the user has that right if they have an "allow" with no denials. This may seem a little redundant, but...
- A deny in any of the user's groups means it's denied, period.
- If the user has no "Allowed" in any groups (e.g. they are all "X"), then it's denied.
- The only way a right is "Allowed" is if at least one of the user's groups have "Allowed", and none are "Deny".

And as I said, at present (1.1) SMF uses an aggregate group model - a user can belong to several groups, and that's it.

An inheritance model is slightly different - with inheritance, both users and groups can belong to a group... and that's the difference. The actual existence of a right is still determined the same way.
The result is a little more natural in some applications. Consider the following scheme -

Guests
Everyone
Advanced
SuperUser

Ideally, the "Everyone" would have the base rights that "everyone" gets, excepting guests. SMF currently treats "Guests" as a unique group.
The "Guests" group would probably have some denials cast into it, etc.
"Advanced" would be the base rights that all advanced users get - additional board access, posting rights, etc.
"SuperUser" might grant some additional rights, such as post editing, calendar editing, or whatever.
And in a perfect world, done correctly, there will be no duplicate rights specified - the "Everyone" group specifies the common rights that all users get, the "Advanced" group specifies exactly the additional rights granted by that role, and the "SuperUser" group specifies exactly the additional rights that are granted by that role... no overlap between groups without a specific reason.

With an aggregate model (currently used in 1.1), a super-user would need to be placed into "Everyone", "Advanced", and "SuperUser".  That's a bit of a pain in some cases... groups are typically based on a "role" based philosophy (e.g. what functions do you need, or what is your role here); we (the admins) must remember all of the groups that a user will need.

With an inheritance model, during setup, I'd make the "Advanced" group a member of the "Everyone" group - literally, you add that group to the "Everyone" group just like you do with users.  And then I'd make "SuperUser" a member of the "Advanced" group.

Come the time to make my user a "SuperUser", I simply remove them from whatever group they're in, and put them into the SuperUser group - and they "inherit" all of the rights that the SuperUser group belongs to ("Advanced", which belongs to "Everyone").
In this scheme, a SuperUser's membership in "Advanced" and "Everyone" is implied, rather than explicitly stated.  It makes rights management much, much cleaner.

And, an inheritance model still works as an aggregate model - there's nothing that says I can't put a user in several groups, just as we do today. But for more complex setups, inheritance is a must.

Make a board, "SpecialBoard 1".  Make a group, "SpecialBoard 1 Access", and give that group access to that board. Noone else.
- You can add specific users to the "SpecialBoard 1 Access" group (as is done today), and/or...
- You can add specific groups to the "SpecialBoard 1 Access" group. Literally, I'd make the board public by adding the "Everyone" group to the "SpecialBoard 1 Access" group.

For Joe, a SuperUser, he'll inherit access to SpecialBoard 1 - SuperUser inherits from Advanced, which inherits from Everyone, which inherits from SpecialBoard 1 Access.  But when you look at Joe's profile, the only group turned on is "SuperUser".  Groups begin to act more as roles than as a simple collection of rights.

If you think of "inheritance" from an e-mail list perspective, it's quite obvious - just look at the org chart for a given company, and the groups become obvious.

Everyone
-- Operations
---- Technical
---- Building & Maint
---- P&E
-- Administrative
---- HR
---- AR
---- AP

Making email lists for this structure, "inheritance" really shines.  I'm in the IT department, "Technical".  So, I make a distribution group called "Technical", and me and my pals are in it.  I also make one for the Maint guys, and one for the P&E guys.
I then make a group called "Operations", and simply throw the "Technical", "Maint", and "P&E" groups into it.  Wash, rinse, repeat with the other sections of the company.  Finally, I put "Operations" and "Administrative" into the "Everyone" group, and I'm done.

Come e-mail time, you can mail to "Technical" and get us.  Or, mail to "Operations" and get... everyone under the Operations group.  Meanwhile, I can add/remove people from the "Technical" group, and *not* need to know that hierarchy (as you would need to, with an aggregate model).  If we decide to fire Fred tomorrow, I don't need to run through every group to find where he is - he's in Technical, so when I remove him from that group he's automatically out of Operations and Everyone. Likewise if we hire Jim, I throw him into Technical, and he automatically inherits Operations and Everyone.

So, that's what inheritance is, and why we use it - it allows us to manage things based on Role, without knowing (or remembering, actually) all the specific details that are implied by that role.

[shentino]

Um...so can one group be part of more than one group at a time?

Like I want "player" to be part of "game people" and "specially privileged over newbies".  Likewise, "wizard" woudl be part of both "game people" and "staff".

Can group A be part of groups B and C?

And what about cyclic inheritance.  Two tight groups that are both part of each other.

Can group A be part of group B even if group B is a part of group A?

[metallica48423]

The basic premise of inheritance is simple, though smurfbutcher bob's post goes into a great amount of detail.

Say you have two groups, Group A, and Group B.

Group B is set to inherit permissions from Group A.

You have a member that is a member of Group B, but not Group A.

That member and any in group B will have the same permissions as anyone Group A.  Note that this does not include board access.

Thered be no need for cyclic inheritance, the two groups would be seperate groups but inherit the same set of permissions.  Changing the permissions of Group A would change the permissions of Group B.

I can't see any reason for a group to be set to inherit two groups of permissions, it'd get the one with the most permissions - always, unless some are set to deny by another of the member's groups.

Remember that in a typical board setup members will be usually only in the regular members group.  'Staff' as you may call it, may be in multiple groups, however.

The premise and idealism behind the system is that when you have many groups that all have the same permissions, if theres a lot, and you have to make a change... thats a lot of changes!  In this case, it'd be one change.

[Smurfbutcher Bob]

Note that this does not include board access.

Hmm... the whole point is to avoid the nightmare of permutations.  I'd suggest throwing in "board access" (with full "allow" "X" "deny") as a feature request, as board access is one of the worst offenders.

I can't see any reason for a group to be set to inherit two groups of permissions, it'd get the one with the most permissions

Not sure you worded that the way you wanted - when group A inherits from multiple groups, it inherits *the sum* of those rights - not just from the one with the most. Hence the idea of not having much overlap in what rights are assigned (avoid assigning the same right to a 2nd group without a reason).

Group A has "read" right.  Group B has "write" right.
Group C has no rights, but belongs to both A and B.
User belongs to Group C.  User has "read" and "write" rights.

Remember that in a typical board setup members will be usually only in the regular members group.  'Staff' as you may call it, may be in multiple groups, however.

Quite true, until "specials" are introduced - be it private feature boards, or (what SMF is *really* good for) added packages. Especially when SSI is considered - SMF provides a really fun platform for some really fun projects, specifically because the permissions are easily integrated. I've written a couple for in-house use, and in general - you're right. But, I've shied away from anything "permissions heavy", exactly because of the current flat-model. SMF would make one heck of a platform for a CRM, or a project manager, or a ticket system, or lots of things when you think about it - and in those cases, multiple membership would be common.  Ya gotta remember, there's more to this rights strategy then just the base SMF product

But to Shen's example of group A having two parents (B and C), it is quite legitimate, and done frequently in the real world.  "Wizard" belonging to "game people" and "staff" is a perfect example.  Just as a user can belong to multiple groups, a group can as well.

Having multiple parents isn't just for hierarchies; where group inheritance shines (in the communication arena) is with ad-hoc groups. And in the wonderful world of a forum "community", the ability to send messages (PMs, email, or view board posts) to groups is wonderful. In that case, a chunk of the user's group memberships won't be based on board function - they'd be based on user's interests.  And in that case, it'd be common for a group to have multiple parents.  Think "board access" in a forum hosting multiple (parallel) communities - you'll have management people, sales pigs (per division), operations, techs, grunts, minions, and every other "role" in a given company - and each would have specific boards that they'd be allowed to see. Meanwhile, the forum might also be cut up by geography - NorthEast, West, etc. There's a whole other group hierarchy in parallel. And again for any other social structure that'd make sense (gender, chain-of-command, project membership, whatever).  While a little extreme for the usual SMF installation, it *IS* the general case.   ("Anything that might only happen once... IS going to happen.")

Cyclic inheritance, logically, is a race condition (malformed tree) - while most recursers will handle it, it IS technically an error in a hierarchy model. Typically the group manager will "keep" the first instance of a group that's encountered, and discard any additional references to it (to prevent an infinite loop). The downside being that you lose any positional context of those group placements, if position plays a role in the inheritance scheme (think "group policy" ala Windows, or other precedence schemes where depth is a factor).  So, it should handle it (silently, as an error), but it's technically wrong for an admin to create such a relation.

Hope that clarifies!
- sbb

[metallica48423]

As long as that post was, i found it fun to read   The logic is presented very well

You are correct, that is perhaps an incorrect phrasing, you are indeed correct that it is effectively the "sum" of the permissions.

Thanks for the excellent and succinct explanation of something that can be actually very complex (permissions )

[shentino]

Ok,

Group G has certain permissions, and group P has certain other permissions, some of which contradict group G's permissions.

If a member is in group P (and thus in group G), would allows and denied from them be collected together and then applied as a single collection, or would P permissions override G permissions in the event of conflict?

...If permissions ARE a simple lump sum for all ancestors (including superclasses), then why would order matter, or why would cyclic inheritance be a problem anyway?  A tangle of #pragma once\n#include may not have any guarantees about ordering, but all the files will (eventually) be included, and as long as order isn't important, there won't be any problems...I think...

*scratches head*

Cyclic inheritance falls more into "if it can handle this without breaking then I'll eat my hat".  There might not actually be a good use for it in practice, but it sure would be cool.  Robustness never hurts

[Smurfbutcher Bob]

Heh, good question.

Group G has certain permissions, and group P has certain other permissions, some of which contradict group G's permissions.
If a member is in group P (and thus in group G), would allows and denied from them be collected together and then applied as a single collection, or would P permissions override G permissions in the event of conflict?

This answer depends on your strategy - hence my reference to "depth", earlier. 

In some designs, "depth" dictates precedence - usually "last one" wins, or perhaps "first one" wins. It's up to the programmer.

If you thinks along the lines of (the abortion known as) Windows Group Policy objects - literally, a GPO is a hierarchy of registry settings that get applied to a machine/user, using a depth-based precedence (last one wins).  If the top-most policy says "Disable windows update", and the 3rd policy says "ENable windows update"... the 3rd policy will win.

Depth based precedence, as it turns out, didn't prove too useful when it comes to most security systems. Most of the good ones go with a "Default Deny" strategy:

- User has zero implied rights.
- To gain a right, it must be specifically allowed and NOT DENIED.

So in SMF parlance ("Allowed", "X", "Denied") - for a permission to Post -
If all of his groups are "X", then he doesn't have the right.  "X" means "not specified".  And since none of the groups specified the right, the default is Deny.
If ANY of his groups are set to "Deny" that right, then it doesn't matter what the others are.  The right is denied, period.
If NONE of his groups are set to "Deny", and at least one is "Allow"... then he gets the right.

...If permissions ARE a simple lump sum for all ancestors (including superclasses), then why would order matter, or why would cyclic inheritance be a problem anyway?  A tangle of #pragma once\n#include may not have any guarantees about ordering, but all the files will (eventually) be included, and as long as order isn't important, there won't be any problems...I think...

... until the user beats you over the head with his monitor after having to wait 30 minutes for each keyhit to be processed.  Cyclics are great in the offline "go get a cup of coffee while we wait" world. But in practice they are several dozen orders of magnitude slower, and offer no value for it (they do nothing that the "last man" or "default deny" tactics would provide).  They're exactly a great "shotgun solution" to poorly organized  (or poorly predictable) systems, at the cost of horrible scale ability.

Cyclic inheritance falls more into "if it can handle this without breaking then I'll eat my hat".  There might not actually be a good use for it in practice, but it sure would be cool.  Robustness never hurts

Hehe, that's one of those new definitions of "Robust" that I've not heard yet.   But I'm not one to talk, I've written my share of it, for sure   

[shentino]

Ok, so as far as permissions are concerned, what matters is what groups a user is in, and not what order he's in them in? (wow, that was a tonguetwister )

Just want to make sure I got this thing down pat.  I have plans for a fairly complicated heirarchy and I don't want any nasty surprises biting me in the arse.

Btw, P meant "parent", and G meant "grandparent"

[Smurfbutcher Bob]

Correct, order is not relevant - it's just the result that counts (and the only difference between an aggregate and an inheritance model - the inheritance allows for recursion, e.g. groups belonging to groups.)

[shentino]

Glad for that.

Btw, I figured out a way to speed up such checks.

Maintain "effective permissions" for each group based on what they inherit, and invalidate (or regenerate) these caches whenever group settings change.

Also, a warning for if you add a permission in one group that one of it's ancestors contradicts (such as allowing an ancestor-denied), would probably be help, since the admin is doing something nop exactly obvious (spelling pun intended).

[shentino]

THanks again for the info.  I'll go cancel my feature request then