[dev] Horde Perms

[Ralf Lang]

Am Sonntag, 14. August 2011, 04:00:42 schrieb Gonçalo Queirós:
> On 08/13/2011 02:44 PM, Jan Schneider wrote:
> > Zitat von goncalo.queiros at portugalmail.net:
> >> Hi there.
> >> 
> >>  Started to dedicate some attention to Horde Perms, and there seems
> >> 
> >> to be
> >> 
> >> some odd behaviors with it:
> >>  - If i give to user A permission to kronolith:max_events = 2, he
> >> 
> >> will be
> >> able to create only 2 events, but every other user won't be able to
> >> create
> >> any event.
> >> 
> >>  I then give all authenticated users permission to create 5 events,
> >> 
> >> and my
> >> user A will now be able to create 5 events too. Digging the code i
> >> saw that
> >> Horde_Perms just returns to Kronolith an array('2', '5'), and then
> >> Kronolith uses the max of the array.
> >> 
> >>  As a user pointed on the IRC, i could add all users to a group, give
> >> 
> >> that
> >> group permissions to create 5 events, and give user A permission to
> >> create
> >> 2. While this would probably fix the problem, it doesn't seem right
> >> because
> >> every time a user registers i would need to add him to this group.
> > 
> > There's nothing odd about this. Permissions are additive. You cannot
> > further restrict permissions that a user gained by other permissions.
> 
> Sorry, but i don't understand how does it make sense. If I deny a
> permission to a specific user, im also obliged to allow the permission
> to all access users (otherwise, none will have it), and since they are
> additive, it actually doesn't matter what i set to the specific user.
> Currently you can't deny access to one user to an application, and still
> allow all authenticated users to access it..

Yes. You do not "deny" access or thresholds but "allow" it on several levels. 
If the permission exists, it's denied by default. If not, just the other way 
around. I think it was that way back in H3. For denial, a simple checkbox 
would not be enough. You needed to mark if you mean "go with higher level 
settings" or "explicitly deny". This whole thing would get messy with 
countable permissions - You would need to indicate if a number may be 
overriden but this doesn't work. Nobody prevents you from marking two 
overlapping permissions as "don't override" or put users in groups they were 
not in before and so on. You could settle with "specific overrides general" 
but this still doesn't apply to all situations. In the end, you would mark 
every countable permission as either "no lower than this", "no higher than 
this" or "overridable default". Not only storage and calculation, also the UI 
needed to be different to allow the user overview all the implications of a 
permissions change on any level.

This all can really be circumvented by just putting all good guys in a 
"normal" group and the lesser users into a "I don't trust you guy" group and 
assign permissions on this level instead of "all authenticated". 

Though it would be handy if there was a setting "put new users into default 
group". Probably you could do this by a hook or through the signup form.

-- 
Ralf Lang
Linux Consultant / Developer

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537