[SSSD] Unexpected behavior with 'simple_allow_users ='

Dmitri Pal dpal at redhat.com
Tue Nov 6 18:54:46 UTC 2012


On 11/06/2012 01:45 PM, Simo Sorce wrote:
> On Tue, 2012-11-06 at 13:12 -0500, Dmitri Pal wrote:
>> On 11/06/2012 10:50 AM, Simo Sorce wrote:
>>> Just to be clear this is how I see it:
>>>
>>> config file  |   confdb     |   result
>>> ----------------------------------------------------------
>>> no attr      |   'ALL'      |  all user can access
>>> empty attr   |    NULL      |  access is denied to all
>>> user1, user2 | user1, user2 | only user1, user2 can access
>>>
>>>
>>> Simo.
>>>
>>>
>> I am saying I do not like to hard code anything and rely on configdb
>> contents at all.
>> That changes semantics as in the past we did not rely on its contents.
>> So I suggest to have two config values one is simple_allow_users and
>> another simple_default_allow_rule (or similar, I am not married to name).
>> The table is driven by the contents of the config file only (as it has
>> been in the past with all other attributes):
>>
>> simple_allow_users | simple_default_allow_rule | result
>> --------------------------------------------------------
>> user1, user2       |  ignored                  | user1, user2
>> empty              |  ignored                  | access is denied to all
>> no attr            |  no attr (default = ALL)  | all users can access
>> no attr            |  "all"                    | all users can access
>> no attr            |  "none"                   | access is denied to all  
>>
>> Hope it makes sense now.
> Yes, now I understand what you mean, but it is just too complex.
> It is just not worth doing, it took me several minutes to understand the
> table above, that tells me normal admins will just be confused and
> writing documentation around how it works will be challenging, and we
> call this 'simple' access method.
>
> If this is the complexity we come to I think we should start
> reconsidering the issue from scratch, so I went to the man page to see
> what we say there:
>
>         The simple access provider grants or denies access based on an
>         access or deny list of user or group names. The following rules
>         apply:
>         
>                 • If all lists are empty, access is granted
>                 • If any list is provided, the order of evaluation is
>                 allow,deny. This means that any matching deny rule will
>                 supersede any matched allow rule.
>                 • If either or both "allow" lists are provided, all
>                 users are denied unless they appear in the list.
>                 • If only "deny" lists are provided, all users are
>                 granted access unless they appear in the list.
>
>
> This tells me the expected behavior is that if all lists are empty the
> access is granted (valid for the first 3 points).
>
> For the latter point we just need to make sure that a value of 'ALL'
> does not allow a user in if a deny list is provided.
>
> So adding a default of 'ALL' to simple_allow_users (what I proposed) is
> perfectly consistent with the current behavior (which is why i proposed
> it).
>
> The proposal is that if someone types: "simple_allow_users = " it means
> that no users are in the list and access should simply be denied, this
> currently does not work, access is still allowed.
Following the first bullet in man page "if all lists are empty the
access is granted".
It works as advertised right?
So I do not see why anything needs to be changed then.

>
> We need to decide if we want to change this behavior or not.
>
> If we want to change it then my proposal is sufficient, provided we
> properly change the code, if not then let's do nothing.
>
> I think adding another attribute is simply out of the picture, it makes
> the whole scheme just way to complex just to handle an insignificant
> corner case.
>
> If that's the only viable agreement I propose we simply do nothing.
>
> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list