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

Jakub Hrozek jhrozek at redhat.com
Thu Mar 26 09:11:55 UTC 2015


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/ ?



More information about the sssd-devel mailing list