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.
"""
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.
So could someone explain to me why is the alias problem?
LS
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel