[dev] Horde Perms

[Gonçalo Queirós]

Em 14-08-2011 08:38, Ralf Lang escreveu:
> 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.
I don't think that in the current UI you can see this also. You still 
have to know if the user belongs to any of the groups affected by the 
permission.
> 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.
>
So, in the administrator point of view, instead of a hierarchy 
permission system (creator > user > group > default), it actually sums 
up to the higher permission you ever given to a user.
This would seem acceptable, if you didn't have to move the rest of the 
users to a generic group. Does it make sense? Affect other users, 
because you wan't to change the permissions of one user?
Other thing that doesn't seem right is, everytime i want to give a user 
specific permissions i will have to check if he's in any group that 
might give him higher permissions than those i want to specific give 
him, and remove him from those groups.

Thanks,
Gonçalo Queirós