[Bug 294977] Re: not clear how to configure with pam-auth-update

[Brian May]

Hello,

My initial attempt at pseudo-code of the example was incorrect, I missed
the default=done bit.

Next attempt:

pam_unix.so
if (!success) {
  pam_ldap.so use_first_pass
  if (authinfo_unavail) {
    pam_ccreds.so action=validate use_first_pass
  } else if (success) {
    pam_ccreds.so action=store
  } else {
    pam_ccreds.so action=update
  }
}

Now this makes more sense (action=update - delete - is only called if
authentication failed).

Your patch produces something a bit different:

# here are the per-package modules (the "Primary" block)
auth    [success=4 default=ignore]      pam_unix.so nullok_secure
auth    [success=3 default=ignore]      pam_ldap.so use_first_pass
auth    [success=2 default=ignore]      pam_ccreds.so action=validate use_first_pass
auth    [default=ignore]                pam_ccreds.so action=update
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_ccreds.so action=store
auth    optional                        pam_smbpass.so migrate
# end of pam-auth-update config

Which I think is more like:

pam_unix.so nullok_secure
if (!success) {
  pam_ldap.so use_first_pass
}
if (!success) {
  pam_ccreds.so action=validate use_first_pass
}
if (!success) {
  pam_ccreds.so action=update
  pam_deny.so
}
...
pam_ccreds.so action=store


I guess the main difference is the example will only fall back to
action=validate if pam_ldap.so returns authinfo_unavail, where as this
will fall back to pam_ccreds.so if the passwords mismatch.

ie. consider the case when the user's LDAP password has been changed.
Maybe the old password was compromised. Obviously the old password will
still be valid with the network disconnected. However, here both the old
and new passwords will be valid when the system is connected to the
network again, until the user enters the new password at least once. I
could imagine this could be potentially confusing.


Another difference is it will call action=update if the user enters the
password incorrectly, and there is no network connection.


If I try to log in using cached credentials, it seems to work fine, but
then kicks me off again.

% ssh localhost
brian at localhost's password: 
You have been logged on using cached credentials.
Connection closed by 127.0.0.1

Oh, right, this is probably because /etc/pam.d/common-account was not
updated.

The example config is:

account     [user_unknown=ignore authinfo_unavail=ignore default=done] pam_unix.so
account     [user_unknown=ignore authinfo_unavail=ignore default=done] pam_ldap.so
account     required       pam_permit.so

I don't know why the "user_unknown=ignore" is required, I think the
important part is the "authinfo_unavail=ignore" for the pam_ldap.so
line. Or in the case of the intrepid file, I added "authinfo_unavail=1"
to skip the pam_deny.so


For now I am going to investigate why the action=update doesn't seem to
have any affect.


Brian May

-- 
not clear how to configure with pam-auth-update
https://bugs.launchpad.net/bugs/294977
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs