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