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

Lukas Slebodnik lslebodn at redhat.com
Thu Mar 26 09:30:15 UTC 2015


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.

LS



More information about the sssd-devel mailing list