Permission/Group question

[SBB]

Heya!

Quick question regarding SMFG's treatment of permissions RE: groups -

It appears that it treats permissions with a "default allow" philosophy... anything not specifically forbidden is granted. 

1) Is this true, and
2) Any plans to change it in the future (to make it consistent with SMF's treatment of permissions), and
3) Any caveats with me changing the permission structure to support "default deny"

It's an obscure issue... but it tends to be huge if any non-trivial group management is to take place.

Case study to demonstrate -

I have a gallery with several categories.  Most categories are intended to be viewed by the "ungrouped" users.  One category is reserved for viewing by a specific group, and should be hidden from the "ungrouped".

With stock SMF group inheritence, I'd allow "ungrouped" to have access to all categories except the Reserved one.  For this one Reserved category, I'd not specify any rights at all... literally, the "Reserved" permission for the "ungrouped" group would be unspecified.  This equates to the "X" column in SMF's "A X D" permissions manager.

I'd then create a new permissions group that has the right to view this Reserved category.  If a user wants access, I'd simply add that group to their "additional groups" setting.  (Note that the user's primary group would still be "Ungrouped").

Come time to resolve the various permissions, any right that is not explicitly allowed would be denied.  Any right that is explicitly denied... is denied.  The only rights to survive are ones that are (1) explicitly allowed somewhere in the user's group hierarchy, AND (2) not denied anywhere in the user's group hierarchy.

With the current gallery permissions scheme, you can guess the amount of legwork and group permutations that are required to create this sample setup, with just one single "restricted" category. Add several such categories, and the group counts increase exponentially with all of the various permutations.

Just guessing on the method you used to check permissions, but it acts as if we...
select all rights for user where cat=thiscat
...and basically, if any of the results are a DENY, we don't allow the action.

And that's the problem!  Unspecified rights won't be a DENY... they will be ALLOW.  I'd suggest the following, specifically in this order of processing -
select all rights for user where cat=thiscat
hasrights = .false.
if anyresults = "ALLOW", hasrights = .true.
if anyresults = "DENY", hasrights = .false.
if hasrights... allow the action. Else... do not.

Meanwhile, the current "category permissions" page would need to be updated... the permissions cannot be boolean (checkboxes).  At present, the category options are exactly, "allow" and "deny", based on the presence of the checkmark.  Each permission needs to allow "not specified", as well.

Obviously, it'll have a large impact on group management, making the gallery's permission handling consistent with SMF, and making the gallery more useful for non-trivial applications.

Comments? thoughts? ideas?

[SMFHacks]

Long post you typed up finally have some free time to respond heh.

By default category permissions are setup to allow and you would need to deny any group access.

Starting with SMF 1.1 the software gets rid of the no change permissions and just have allow or deny and that’s what I decided to do for the Gallery so far.

Currently SMF Gallery has two level of permissions.
First is the global permissions found under the permissions page for each membergroup.  For adding a picture, editing a picture, deleting pictures etc

Next we have category level permissions which allow you deny permissions that you granted with global level permissions. If they do not have the global permission that they can not perform that action.    Each group that you want to deny needs to be set only if you granted the global group permissions to do that action.


Things I can see in the future:
Inheritable permissions for subcategories so permissions do not have to be reset for each category.
Permission templates when a category is created such as deny All Groups except admins.

Other ideas I am open to and would like.

[SBB]

Yeah, sorry about the length of that. And of this one.   I swear to god, my conversations are much shorter when spoken 

Inherited groups might be a little tough now that you've straightened me out (re SMF1.1)... sounds like 1.1 might make it difficult for us to cascade them anymore, depending on their implementation.

What I'd suggest is to (magically) allow for cascaded group rights:

I have an 'everyone' group. Everyone is in it, and it is their primary SMF group.

'everyone' has rights to view most of the gallery cats. 'everyone' also defines the common forum rights for the rest of SMF.

I make a 'cool people' group. I add it as a secondary group to a couple of people.

I make a special category, that only cool people can view. I do this by *exactly* giving the 'cool people' group some "allow" rights. I do not specify anything in regards to any other group; the permissions do not exist.

The intent is to emulate how NT's group inheritance works... except that SMF doesn't do inheritance. It does cascade, though... but cascading depends on a "default=deny" when a permission-check yields an empty result.

At present, I create my 'cool guy" category... and 'everyone' can use it. That, obviously, is not desired.
I deny 'everyone', and the cool-guy group can't access it... I literally need to remove the cool people from 'everyone'. The cool people will be thrilled, obviously, because they'll have zero rights (anywhere) aside from viewing that gallery category.

Wash, rinse, repeat if a "hip people" gallery-cat is created, that 'everyone' AND 'cool' should not have access to.

Wash, rinse, repeat if any users are both 'cool' and 'hip', and should have access to both. And again, each of these new permutation of groups will demand a complete "going over" of the rest of SMF's permissions, *everywhere*. Argh!  It rapidly becomes untenable for average humans... especially if someone decides to create a new sub-board over in the forums, it's a total trainwreck. *especially* if that forum is not intended to be public - we literally have to *double* the number of existing groups in order to accomodate the permutations. I'd be looking at about 37 SMF groups to support the 9 groups I have at this point... and adding one single "semi private" board would make it 70.

And if I wish to add a new group... I'll actually need to add 64 of them (making 132 groups, total) to cover the permutations with the existing 70. I've hopefully beaten-to-death the pickle that's created by "default allow", I hope.

So, that's the big change I'd ask you to consider. Instead of All groups are allowed unless specifically denied; users with access *cannot* belong to a group with a denial...  Turn that philosophy around.  All users are denied unless their aggregate-group-rights contain an explicit allowance with no explicit denials!

There's a caveat with this - a group's "permission set" is NOT a single record with "one bool field per permission"... each permission either needs to be tri-state, or needs to be one-to-many'ed out into another table of "cat_id, group_id, perm_id, bool_value" (which would allow the non-existence of a record to indicate it is unspecified).  I obviously did not bring up the case where different groups have different permissions on the same board (moderator? auto-approval? SQUARE the group count because there's two permissions involved!)  IMO, this one-to-many would be the most sql-friendly, since the query would implicitly handle the cascading of unspecified vs. specified perms.

Or, make the permissions into tri-states instead of bools, and handle the cascade in php. It'd be just as fun, but less obnoxious for modders. heh.

Thanks for reading all this*cough*,

- sbb