[SSSD] [PATCH] LDAP: drop lockout option from ldap_access_order

Pavel Reichl preichl at redhat.com
Thu Mar 26 09:12:55 UTC 2015



On 03/26/2015 10:06 AM, Lukas Slebodnik wrote:
> On (26/03/15 09:55), Pavel Reichl wrote:
>>
>> On 03/26/2015 09:48 AM, Lukas Slebodnik wrote:
>>> On (26/03/15 09:26), Pavel Reichl wrote:
>>>> On 03/25/2015 09:53 PM, Lukas Slebodnik wrote:
>>>>> On (25/03/15 14:35), Pavel Reichl wrote:
>>>>>> On 03/25/2015 02:21 PM, Lukas Slebodnik wrote:
>>>>>>> On (25/03/15 14:05), Pavel Reichl wrote:
>>>>>>>> On 03/25/2015 01:51 PM, Lukas Slebodnik wrote:
>>>>>>>>> On (25/03/15 12:01), Pavel Reichl wrote:
>>>>>>>>>> Hello please see attached patch.
>>>>>>>>>>
>>>>>>>>>> The need for this patch was discussed in thread: SDAP: Lock out ssh keys when
>>>>>>>>>> account naturally expires
>>>>>>>>>> This patch implements point number 3.
>>>>>>>>>>
>>>>>>>>>>>> I would prefer if we didn't add a new option as well, but since we
>>>>>>>>>>>> released
>>>>>>>>>>>> a version that only supported the lockout and not any other semantics,
>>>>>>>>>>>> I don't think we can get away with just changing the functionality. A
>>>>>>>>>>>> minor version can break functionality. But a major version can
>>>>>>>>>>>>
>>>>>>>>>>>> So I propose the following:
>>>>>>>>>>>> 1) Add a new value for ldap_access_order called "ppolicy" that would
>>>>>>>>>>>> evaluate the pwdAccountLockedTime fully, including the new
>>>>>>>>>>>> functionality in this patchset
>>>>>>>>>>>> 2) In 1.12, deprecate the "lockout" option and log a warning that it
>>>>>>>>>>>> will be removed in future relase and users should migrate to "ppolicy"
>>>>>>>>>>>> option
>>>>>>>>> The feature was introduced in sssd-1.12.1 and deprecated in sssd-1.12.5
>>>>>>>>> That's really fast progres. The deprecating the features
>>>>>>>>> after half a year.
>>>>>>>>>
>>>>>>>>> Could someone exaplain me why do we need to do such ritual dances?
>>>>>>>>>
>>>>>>>>> LS
>>>>>>>> First there was user ho wanted lockout functionality that is being dropped
>>>>>>>> now. https://fedorahosted.org/sssd/ticket/2364
>>>>>>>>
>>>>>>>> Then a few months later there came another user with
>>>>>>>> https://fedorahosted.org/sssd/ticket/2534 who wished to do something similar
>>>>>>>> but different.
>>>>>>>>
>>>>> I checked bugzilla tickets and the same user requested both features.
>>>> But we can't be sure there are other users using it, can we? IMO we can't
>>>> break their configuration at least not in minor release.
>>> You wrote in previous mail:
>>> """
>>> First there was user ho wanted lockout functionality that is being dropped
>>> now. https://fedorahosted.org/sssd/ticket/2364
>>>
>>> Then a few months later there came another user with
>>> https://fedorahosted.org/sssd/ticket/2534 who wished to do something similar
>>> but different.
>>>
>>> We think that user case addressed in 1st ticket can be handled by
>>> functionality introduced for 2nd ticket.
>>> """
>>>
>>> So if use case addresed in the 1st ticket can be handled by functionality
>>> introduced for 2nd ticket then we can simply drop the 1st functionality
>>> and make an alias from "lockout" to "ppolicy".
>>>
>>> This is very elegant solution which does not break old configurations.
>> Yes, it sounds definitely better as configuration would not break. Only
>> problem I see is the fact that after update some users would not be allowed
>> to log in but they were allowed to do so before update. That's not a security
>> issue and with proper debug message I suppose it could be OK. But I still
>> think that the best think to do is to discuss it on devel meeting.
> It's better to share and keep discussion opened.
>
> The devel meeting is not public :-(.
Sure, I just want to hear opinions of other developers and as they 
probably don't have time to read this bloated thread we can summarize it 
for them and then share their opinion on the list.
>
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list