On Tue, 2014-04-29 at 15:56 +0200, Sumit Bose wrote:
On Tue, Apr 29, 2014 at 09:14:07AM -0400, Simo Sorce wrote:
> On Tue, 2014-04-29 at 13:48 +0200, Sumit Bose wrote:
> > First, forward_pass is not needed here, because it will only forward a
> > password which is requested by pam_sss. In your configuration
> > pam_cracklib will ask for the passwords and put them into the
> > corresponding PAM items. But in case of an error different from
> > PAM_USER_UNKNOWN during the password change pam_sss will explicitly
> > delete the PAM items. Iirc the reason for this was the idea that if
> > SSSD thinks it is responsible for the user but cannot change the
> > password the password should not leak to other pam modules.
> > Unfortunately if SSSD is not running the returned error code will
> > trigger this as well.
>
> This is a bug we should fix
>
> > So I guess should handle the case where SSSD is not running more
> > gracefully here. As an alternative I wonder if the current behaviour
> > is maybe too strict and does not offer additional security and can be
> > removed?
>
> At most we should make it possible to change with an option, but I think
> it is totally appropriate.
Do you think it would be ok to use the 'forward_pass' option for this as
well or do you prefer to add a new one?
Not sure, I do not see any reason why it would hurt, but is there any
case where you'd like to use that option but *not* enable the behavior
we discussed ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York