[SSSD] Unexpected behavior with 'simple_allow_users ='

Ondrej Kos okos at redhat.com
Tue Nov 6 14:10:58 UTC 2012


On 11/06/2012 02:52 PM, Simo Sorce wrote:
> On Tue, 2012-11-06 at 14:46 +0100, Ondrej Kos wrote:
>> On 11/02/2012 05:32 PM, Simo Sorce wrote:
>>> On Fri, 2012-11-02 at 10:10 -0400, Dmitri Pal wrote:
>>>> On 11/02/2012 09:50 AM, Stef Walter wrote:
>>>>> On 11/02/2012 01:57 PM, Dmitri Pal wrote:
>>>>>> First let us define a general rule about how we treat the cases:
>>>>>> X =
>>>>>> Is it treated as X being undefined or X having an empty value.
>>>>>> It should be a general documented rule for the application.
>>>>>>
>>>>>> Current behavior is to ignore and I think it is the right one.
>>>>>> May be it should be clearly stated in the man for sssd.conf if not yet
>>>>>> stated.
>>>>> Understood.
>>>>>
>>>>> But to me it seems that this policy does not make sense in this
>>>>> situation. It's completely counter intuitive that the following, instead
>>>>> of allowing no users, allows any user.
>>>>>
>>>>> simple_allow_users =
>>>>>
>>>>> Sure, you can say that anyone deploying sssd, should read over every
>>>>> line of the documentation and be well informed.
>>>>
>>>> One does not preclude the other. The point about man pages is just to
>>>> make a statement explicit not implied. I do not expect everyone to read
>>>> it but it is better to be explicit.
>>>>>    But there's also
>>>>> something to be said for readability and principle-of-least-surprise.
>>>>
>>>> Sure. Whatever we decide should be consistent and logical.
>>>> I seems that so far we had the rule that empty values are ignored.
>>>> Is it consistent and logical to change it for one attribute?
>>>> I doubt but your argument is valid too.
>>>> May be the way out is to have a different attribute
>>>> simple_default_allow_rule = [all] | [none]
>>>> By default it will be "all" meaning that if the simple_allow_users is
>>>> not specified or empty then all users are allowed - current behavior
>>>> If it is set to none then if the filter is not specified no one is allowed.
>>>>
>>>> Would that be more logical?
>>>
>>> I was thinking along these lines too.
>>>
>>> If we have a default of ALL, then 'none' is not necessary at all as long
>>> as a 'simple_allow_users = ' line in the conf causes the attribute to be
>>> completely removed from confdb
>>> at that point the code, not finding the special default of 'ALL' would
>>> cause everyone to be denied as Stef expects.
>>> The bonus is that an admin can explicitly allow all by setting ALL,
>>> which is also clearer than having to delete the configure attribute or
>>> disable the access check plugin.
>>>
>>> I do not like the $ suggestion as in Windows machine names have the $
>>> sign in it so $none$ and none$ would be valid yet easily confused.
>>>
>>> 'ALL' is used in many tools so it is unlikely someone will have an upper
>>> case user or group name named that way, and if so .. well I guess they
>>> will have to cope.
>>>
>>> There is one other character that nobosy uses in usernames and that is
>>> ':' because historically that's the spearator in /etc/passwd so it
>>> simply can't be used in the user name.
>>>
>>> So maybe ':ALL' is also a possibility, or maybe we consider ':ALL' the
>>> 'escaping' version to be able to reference and actual entity called
>>> 'ALL' (I would prefer the escaping rule).
>>>
>>> Simo.
>>>
>>>
>> So should i prepare patch introducing this behaviour?
>>
>> - add configuration option
>>     simple_default_allow_rule = [true|false] / [all|-?-]
>>
>> - if <false>
>>     simple_allow_* list would be expected to contain some users/groups,
>> empty list results in no-one being allowed.
>>
>> - if <true|all>
>>     all users are allowed by default, limitations are derived from
>> simple_deny_* lists.
>>
>>
>> is this correct?
>
> Nope
>
>>   or should we use something like:
>
> This is what we were proposing.
>
>> simple_allow_users = <ALL_keyword> | <user list>
>>
>> and not add the new option at all? in that case, what would be the
>> keyword and how should we handle the situation, when the configuration
>> file would contain the following:
>>
>> simple_allow_users = <ALL_keyword>, user1, user2, ...
>
> users here would simply be redunant as the ALL keyword alreay matches
> everyone.
>

the question here is, should we treat this as an configuration error, or 
allow it?

>> also this method would require *simple_allow_users* rule to be present,
>> or would be handled as empty.
>
> when empty it will mean that nobody is allowed. (the default internally
> if not present at all is 'ALL'

that is the problem. we can't distinguish if list is empty or not 
present at all without modifying confdb

-- 
Ondrej Kos
Associate Software Engineer
Identity Management
Red Hat Czech

phone: +420-532-294-558
cell:  +420-736-417-909
ext:   82-62558
loc:   1013 Brno 1 office
irc:   okos @ #brno



More information about the sssd-devel mailing list