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

Pavel Reichl preichl at redhat.com
Thu Mar 26 09:41:27 UTC 2015



On 03/26/2015 10:30 AM, Lukas Slebodnik wrote:
> On (26/03/15 10:22), Pavel Reichl wrote:
>> On 03/26/2015 10:19 AM, Lukas Slebodnik wrote:
>>> On (26/03/15 10:11), Jakub Hrozek wrote:
>>>> On Thu, Mar 26, 2015 at 09:55:46AM +0100, 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.
>>>> Yes, I really don't want to remove functionality in a .z release.
>>>>
>>>> I don't think we need to be bound by the bugzilla either. Let's do
>>>> upstream what's best for upstream -- in my opinion it's deprecating the
>>>> option in sssd-1-12 so that existing users might migrate until they
>>>> prepare for sssd-1-13. Then removing the option in sssd-1-13.
>>>>
>>>> Is that acceptable for /upstream/ ?
>>> I still don't understand why we need to deprecate the option.
>>>
>>> Pavel claims:
>>> """
>>>     We think that user case addressed in 1st ticket can be handled by
>>>     functionality introduced for 2nd ticket.
>>> """
>> Lukas I also wrote:
>>> 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.
>> It similar but not the same.
>>
> It wasn't mentioned at the beginning.
>
> If they are not the same the I do not agree with removing this feature.
> Because they can be user which can rely on such behaviour and
> it could be considered as a REGRESSION.
>
> So please decide if they are the same or aren't.
>
>
Lukas you are  quoiting  just part of my message:

"""
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.
"""

You also said:
"""
I mentioned it as a part of review a month ago.
So you needn't explain it to me.
"""

So I supposed you knew the difference between  the options.



More information about the sssd-devel mailing list