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