Re: Support for pam_ldap configuration

[Arthur de Jong <arthur [at] arthurdejong.org>]

On Mon, 2012-07-02 at 16:07 -0700, Ted Cheng wrote:
> I am submitting a patch, attached, for consideration to be included in
> the nss-pam-ldapd release:
> 
> Added pam_ldap configuration support with an additional
> NSLCD_ACTION_PAM_CONFIG protocol call to the server.
> The call takes two types of requests:
> 
> (1) NSLCD_PAM_CONFIG_INIT: request for all available configuration
>     flags, returned as an integer.
> (2) Request for individual config parameter value. Currently
>     NSLCD_PAM_PWD_PROHIBIT_MSG is implemented, which disallows
>     passwd changes when pam_password_prohibit_msg paramter is
>     specified on on server side.
> 
> The pam_ldap client side changes are #ifdef'ed
> NSLCD_PAM_CONFIG_SUPPORT. The OpenLDAP nssov server side
> implementation is provided in server_pam_config.c for reference.

Thanks, this looks very interesting. Perhaps it is a good idea to make
it a bit more generic. I have been struggling a bit with a way to have
the PAM module query nslcd whether the root user can modify a user's
password (basically whether the rootpwmoddn and rootpwmodpw options are
set). Something like this could also be even used to pass configuration
information to the NSS module if needed.

Anyway, I have a few notes on your patch:
- why did you split the request into two parts? wouldn't it be simpler
  to just do error handling for the second request?
- the requests could probably be done in the pam_sm_chauthtok() function
  since they aren't needed for all PAM calls
- currently the enforcement check is in pam_sm_authenticate() but
  shouldn't it be in pam_sm_chauthtok() instead? I don't think this
  handles the case where the password is changed by another application
  and it could cause problems for password modification of non-LDAP
  accounts.
- how is this implemented in the LDAP server? is it an attribute
  somewhere or is it in the nssov configuration option? (just curious)
- it doesn't gracefully handle the case where the server side (nslcd)
  doesn't implement the request; this could be an issue during upgrades
  where the client-side has been upgraded but the server hasn't been
  restarted yet

Attached is an untested patch with an alternative implementation based
on your idea. It uses a single request and only uses the result if there
was no error in getting the configuration. What do you think?


Btw, I have been playing with the idea to change the nslcd protocol but
have been putting this off due to compatibility issues (both during
upgrades and compatibility with nssov).

One issue that needs to be addressed is that integers will have to be
sent in network byte order instead of host byte order for multiarch
systems with that support mixed endianness (see
http://bugs.debian.org/659488).

Another is that I don't really like some of the small inconsistencies in
the PAM protocol. Not all request parameters are always in the same
order and I don't like passing the userdn back and forth much (nslcd
currently ignores the userdn for most requests). Also, the password
modification request doesn't really work very well with password
modification as root.

Do you have any preference on how to handle this from the nssov side or
have any ideas on this? It is not something I want to rush into.

Thanks,

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --

Attachment: nss-pam-ldapd-implement-config-request.patch
Description: Text Data

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/