[dev] Horde Perms

[Gonçalo Queirós]

Em 15-08-2011 21:57, Jan Schneider escreveu:
>
> Zitat von Gonçalo Queirós <goncalo.queiros at portugalmail.net>:
>
>> 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.
>
> Yes, it makes sense, because it's much more likely that you want to 
> extend permissions for individual users than that you want to restrict 
> them.
>
> Jan.
>
While it can be much more likely to extend permissions than to restrict, 
if you run a system with 1 Million users its not that practical to 
create a group to fit all this users just to restrict a single user's 
permissions don't you think?

Thanks,
Gonçalo