Deprecating pam_stack.so

[Bernardo Innocenti]

Tomas Mraz wrote:

>>  - For some reason, pam_ldap interacts strangely with pam_unix.
>>    Even tough pam_unix comes before it and is "sufficient",
>>    nobody can login when the network is down or slapd is down.
> The pam_ldap module will reject login in the account phase. You can use
> pam_localuser (supported by authconfig) to make pam_unix authorization
> of local users sufficient.

Thank you.  I've regenerated my /etc/pam.d/system-auth with
system-config-authentication and enabled the localuser module.

Login with local user accounts still failed because nss_ldap
tries too hard to connect to the LDAP server and incurs in
the 60 seconds timeout of /bin/login.

I've fixed it by setting these options in my /etc/ldap.conf:

 # Search timelimit
 timelimit 3

 # Bind timelimit
 bind_timelimit 2

 # Reconnect policy: hard (default) will retry connecting to
 # the software with exponential backoff, soft will fail
 # immediately.
 bind_policy soft


I wonder if values like these should become the Fedora defaults?
A system that just hangs when you pull the ethernet cable doesn't
make a good impression with most users.


>>    Also, you can login as root with root's password from ldap
>>    even tough there's a valid root entry in /etc/passwd.
> That's expected as both pam_ldap and pam_unix are sufficient entries.
> If you want to prevent that you can insert pam_succeed_if

Sorry, I don't quite understand how to set it up to reject uid == 0
just for pam_ldap and not for pam_unix.

I also don't understand what the "uid < 100" condition inserted
by system-config-auth is for.

My current config is:

 auth        required      pam_env.so
 auth        sufficient    pam_unix.so likeauth nullok
 auth        sufficient    pam_krb5afs.so use_first_pass tokens
 auth        sufficient    pam_ldap.so use_first_pass
 auth        required      pam_deny.so

 account     required      pam_unix.so broken_shadow
 account     sufficient    pam_localuser.so
 account     sufficient    pam_succeed_if.so uid < 100 quiet
 account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
 account     [default=bad success=ok user_unknown=ignore] pam_krb5afs.so
 account     required      pam_permit.so

 password    requisite     pam_cracklib.so retry=3
 password    sufficient    pam_unix.so md5 shadow nullok use_authtok
 password    sufficient    pam_krb5afs.so use_authtok
 password    sufficient    pam_ldap.so use_authtok
 password    required      pam_deny.so

 session     required      pam_limits.so
 session     required      pam_unix.so
 session     optional      pam_krb5afs.so
 session     optional      pam_ldap.so



The man pam_succeed_if man-page says it can suceed _or_ fail,
but it only seems to 


>>  - Many pam.d files still use the absolute path "/lib/security/$ISA/"
>>    that doesn't seem to be useful anymore and looks weird on
>>    bi-arch systems such as x86_64.
> They will be converted during the change to use include instead of
> pam_stack.

Nice.  system-config-authentication already wiped the paths out
when it rewrote system-auth.


>>  - Something similar of pam_ssh would be much cleaner than the
>>    current hack of running ssh-agent in GDM's session.  gpg-agent
>>    support would also be welcome.
> This is a problem as the passphrases for ssh keys can be different from
> the user's system password. So the pam_ssh is definitely not a
> replacement for ssh-agent.

Yes, we would need half of what pam_ssh does: instead of authenticating
the user against his ssh key, it should just load the key iff the
passphrase happens to match the account password.

Maybe this other project would be more appropriate:

 http://sourceforge.net/projects/pam-ssh-agent/

 PAM module that spawns a ssh-agent and adds identities using the
 password supplied at login.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/