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

Stephen Gallagher sgallagh at redhat.com
Mon Nov 9 13:05:32 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/09/2009 07:55 AM, Brian J. Murrell wrote:
> On Thu, 2009-11-05 at 16:27 -0500, Brian J. Murrell wrote: 
>>
> 
> I didn't see any response to the following.  As far as I can see and
> have explained this is still a problem.  If you disagree, please present
> your argument so that I can take it back to the pam_unix folks for their
> consideration.  But so far, as far as I can tell, pam_unix is doing what
> it should and it's sssd that's in error.
> 
> Cheers,
> b.
> 

Sorry Brian, we discussed this off-list in #freeipa the other day.
Transcript included here for posterity.


======================================================================
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.
(08:31:01 AM) simo: sbose, is this in the password checing code?
(08:31:27 AM) simo: sbose, I think Brian was talking about the "Access"
target
(08:31:48 AM) simo: sbose, sorry I mean "account" target :)
(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
(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.
(09:06:01 AM) simo: sbose, yes
======================================================================
>> Hrm.  Is this supposed to be cause or effect?  i.e. should an encrypted
>> value for a password being an "*" actually mean to any login programs
>> that this account is locked, or does it just mean that there is no way
>> that pam_unix (or any-other crypt-style login process) will be able
>> decyrpt this as a password and the side effect of that is that the user
>> will not be able to login [using a crypt-style login]?
>>
>> I read "If the encrypted password is set to an asterisk, the user will
>> be unable to login using login(1)," more as effect than cause.
>>
>>> but may still login using rlogin(1), run
>>> existing processes and initiate new ones through rsh(1), cron(1), at(1),
>>> or mail filters, etc"
>>
>> Which I think further validates that an "*" doesn't mean "no login
>> allowed", just "login through decrypting a password will not be
>> possible".
>>
>> The summary being that an "*" should be perfectly viable for a non-crypt
>> based authentication scheme, like, oh, say, kerberos.  :-)
>>
>>> On the other hand, an "x" indicates that the password is maintained in
>>> the shadow map,
>>
>> Right!
>>
>>> which we do not export through SSSD and would therefore
>>> imply denial for all attempts to authenticate.
>>
>> I'm not sure what point you are trying to make here.
>>
>>> This way we can do authentication using only the auth_provider specified
>>> in the domain, without worrying about pam_unix.so stepping on our toes.
>>
>> But pam_unix.so will step on your toes.  When used in the account mode,
>> pam_unix sees the "x" for the password and that tells it that there
>> should be shadow information available and it wants to verify the
>> details of the shadow information to see if the account is in good
>> standing, not in need of a password change, etc.
>>
>> But because we have (and we shouldn't in fact have -- so this is the
>> proper operation IMHO) no shadow information when using the kerberos
>> auth_provider, it's erroneous to tell pam_unix.so that there is shadow
>> information available by sending an "x" in the password field of the
>> passwd entry.
>>
>> Try it.  Create a configuration that allows you to login without a
>> shadow entry (i.e. kerberos, or maybe ldap even) and configure your nss
>> provider to not provide a shadow entry and then put a pam_unix.so entry
>> in your account configuration such as:
>>
>> account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so 
>> account requisite                       pam_deny.so
>> account required                        pam_permit.so
>> account [default=bad success=ok user_unknown=ignore] pam_sss.so
>>
>> And then see what difference is made by an * and an x in the password
>> entry of the passwd map when there is no shadow entry available.
>>
>> Here it's the difference between being allowed to ssh in and get to a
>> and being authenticated, but still denied acceess (because of the failed
>> attempt to verify the shadow information.
>>
>> Once you have confirmed the latter effect, comment out the first two
>> lines of the pam account settings above and try again.  You will now be
>> allowed to log in without a shadow entry.
>>
>> If you want further proof, change your id provider to make the password
>> field of your passwd entry a "*" instead of the "x", reinstate the first
>> two lines of the pam account above and try to log in again without a
>> shadow entry.  It will succeed.
>>
>> b.
>>
> 
> 
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4E5cACgkQeiVVYja6o6MU0ACcCwm0wtkPR1lyj151CeUOQefP
jj0An2k3xq26WaDpoP3qhL51YTx6clHl
=ulpI
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list