[dev] Horde Perms

[Jan Schneider]

Zitat von Gonçalo Queirós <goncalo.queiros at portugalmail.net>:

> 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?

That's why there are default permissions.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/