Geeklog Forums

owner_id | mediumint(8)
group_id | mediumint(8)
perm_owner | tinyint(1) unsigned
perm_group | tinyint(1) unsigned
perm_members | tinyint(1) unsigned
perm_anon | tinyint(1) unsigned

I'm working on a few bugs related to the Rating Plugin and have a security question on how groups should work.

Currently lets say user Test is setup and belongs to the Rating Admin Group. This group has the following privileges rating.edit rating.moderation and rating.view.

Now the admin creates a rating and saves it. So the record has the owner_id = admin, group_id = Rating Admin Group and then perm_owner=3,perm_group=2,perm_members=2,perm_anon=2.

Now with this setup should the User Test have edit access to this rating? I think he should since he belongs to the Rating Admin Group. My problem is that the perm_group is set to read only (2). Which should have priority?

Can someone explain the how security should work when dealing with group_id and perm_group and the actual admin group for the plugin.


Thanks

---

One of the Geeklog Core Developers.

You are focusing on the name of the group. What if the group was named "XYZ", should it automatically give you admin rights?
Being memmber of a group does not automatically give you rights to edit items. Exactly how this works is ofcourse implementation dependant (i.e. you might say "if a user has access right abc.admin rights the group setting is overridden", but the standard behaviour in GeekLog is that you must have write access AND some access right (i.e. you must have write access as owner or by group membership AND you must hav right abc.admin in order to to X).

So groups works two ways. First it is used to determin R/W rights but in order to actually perform a specific action secutity features are also checked and what security features you have are also assigned using groups.

---

Geeklog Plugins: http://plugincms.com

The first thing to understand is this; the features (or privileges as you call them) have no direct bearing on whether a user can read/write to an item. The feature rating.edit does not give any type of permission, it is simply an attribute that you can use in your plugin code to determine if something should happen.

Let's break it down to the basics first:

Given what you have already stated:


Any user who is a member of the Rating Admin Group will only have READ permissions. This is true if you use the call SEC_hasAccess(). SEC_hasAccess() will look at just the user / group membership and then the perm_* items to determine what permission to give the user.

What you probably want to do is ... if you are using features like rating.admin, rating.moderation and rating.view then you will want to use the call SEC_hasRights( 'rating.admin' ) ;. This will return TRUE if the user has that feature (usually assigned through a group membership). Let's carry forward with your example:

If you assign the feature rating.edit to the group Rating Admin Group, then in your code, you will need to do something like this:


So, based purely on permissions, the user only has READ access, but because the user is a member of the group Rating Admin, which has the feature rating.edit associated, then the user will get level 3 (R/W) access.

Clear as mud?

Hope this helps!

Thanks!
Mark

Thanks for the clarification,

The feature rating.edit gives the group access to be able to edit but not necessary the right unless perm_group is set to edit (3).

---

One of the Geeklog Core Developers.

...or if the user is the owner and the owner have write access. In that case group write access is not needed (but still the feature is needed).

---

Geeklog Plugins: http://plugincms.com