On (26/03/15 10:41), Pavel Reichl wrote: > > >On 03/26/2015 10:30 AM, Lukas Slebodnik wrote: >>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. 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. >""" > >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. Yes I know the difference. IMHO we can simply drop feature #2364 and make an alias from "lockout" to "ppolicy".
But I know that other people can have different opinion. That's the reason why I asked you to decide. I really don't want to have any REGRESSIONS in sssd. LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
