[SSSD] should not return "x" for password when there is no shadow information

Brian J. Murrell brian at interlinx.bc.ca
Mon Nov 9 13:21:35 UTC 2009


On Mon, 2009-11-09 at 08:05 -0500, Stephen Gallagher wrote: 
> 
> Sorry Brian, we discussed this off-list in #freeipa the other day.
> Transcript included here for posterity.

OK...

> ======================================================================
> 07:51:45 AM) sgallagh: sbose: Unrelated: Do you have any comments to add
> on the shadow "x" vs. "*" discussion on sssd-devel? I think Brian and I
> are talking in circles :-/
> (08:29:07 AM) sbose: sgallagh: concerning '*' vs 'x', I found " } else
> if (!p || *hash == '*' || *hash == '!') { retval = PAM_AUTH_ERR;" in the
> pam_unix source code. So I think pam_unix will always fail with '*', al
> least on Linux.

OK.  But that's for "authentication" which is orthogonal to the issue of
"x" leading to pam_unix wanting to see a shadow entry.  Indeed, I would
expect a password of "*" to fail an authentication check, against the
passwd database (which we ignore of course, when using kerberos.

> (08:38:43 AM) sbose: simo: yes this was authentication, pam_sm_acct_mgmt
> only checks for "*NP*", indicating NIS+, and 'x' or two or more '#',
> indicating shadow, everything else lead to PAM_SUCESS

Ahhh.  So, it seems that sbose concurs that "x" in the password field
does mean there should be a shadow entry available.

> (09:01:00 AM) simo: sbose, ah ok so 'x' is indeed a bad idea ?
> (09:01:29 AM) ***simo tempted to make what we return configurable ...
> (09:02:26 AM) sbose: simo: I think this would be a good idea, because
> how knows how HP-UX handles this.

OK.  So the thought is to make sssd configurable in what it returns in
the password field of the passwd file?

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20091109/83525ddb/attachment.sig>


More information about the sssd-devel mailing list