[Freeipa-devel] [PATCH] 877 prompt for current password

[Martin Kosek]

On Mon, 2011-10-03 at 15:16 -0400, Rob Crittenden wrote:
> Martin Kosek wrote:
> > On Mon, 2011-09-19 at 09:03 -0400, Rob Crittenden wrote:
> >> Jan Cholasta wrote:
> >>> On 16.9.2011 21:16, Rob Crittenden wrote:
> >>>> Prompt for the current password when changing your own password using
> >>>> ipa passwd.
> >>>>
> >>>> I had to jump through several hoops with this:
> >>>>
> >>>> - Added a new sortorder option so the Current password is prompted first
> >>>
> >>> IMO something like "before='password'" would be more readable and
> >>> probably less error-prone than "sortorder=-1".
> >>
> >> The params are sorted numerically based on whether they are required,
> >> have a default, etc. A negative value means it will appear first. This
> >> is intended to be generic enough without having to worry about nested
> >> resolution (A before B, B before C, C before A).
> >>
> >>>
> >>>> - Pass a magic value for current_password if changing someone else's
> >>>> password
> >>>>
> >>>> NOTE: This breaks the API for passwd. There is no way around it. I have
> >>>> this as a minor update as it won't cause older clients to blow up too
> >>>> badly, but their passwd command won't work.
> >>>>
> >>>> rob
> >>>>
> >>>
> >>> Honza
> >>>
> >
> > Generally, it works fine except for the case when user passes its own
> > user name. Do we want to support the following way?
> >
> > # klist
> > Ticket cache: FILE:/tmp/krb5cc_0
> > Default principal: fbar at IDM.LAB.BOS.REDHAT.COM
> >
> > Valid starting     Expires            Service principal
> > 09/23/11 09:48:05  09/24/11 09:48:05  krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM
> >
> > # ipa passwd fbar
> > New Password:
> > Enter New Password again to verify:
> > ipa: ERROR: Insufficient access: Invalid credentials
> >
> > Maybe we could throw an error when user passes its own principal to ipa
> > passwd command. After all, this argument is for changing _other_ user
> > passwords.
> >
> > Martin
> >
> 
> Fixed. The username wasn't being normalized into a principal until after 
> the default was set (where we determine whether to prompt for current 
> password).
> 
> rob

I don't think this is the correct patch :-)

Martin