[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#682583: pu: package nss-pam-ldapd/0.7.15+squeeze2



On Fri, 2012-09-07 at 22:53 +0200, Philipp Kern wrote:
> > (1) extra checking of overflows of numeric values retrieved from LDAP
> >     This change was developed and tested by Redhat and has been in
> >     upstream releases 0.7.16 and 0.8.4 (and is also present in the
> >     version currently in testing).
> >     The diff in 0.7.16 which should apply without issues to 0.7.15:
> >     http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1600&view=revision
> >     svn diff -c 1600 http://arthurdejong.org/svn/nss-pam-ldapd
> 
> What's the consequence if we don't include this? I.e. what does this solve
> exactly?

It fixes the range checking code that is in place for checking numeric
results from LDAP. For example it should now correctly reject negative
values and some other out of range values instead of silently converting
them to some other value.

This change also includes proper length checking for the uid attribute
(e.g. when the LDAP server would contain a value that would not fit in
uid_t).

> > (4) increase buffer size for pam_authz_search and ensure log message
> >     isn't cut short (this is Ubuntu bug #951343)
> >     These changes were in 0.7.16 and 0.8.7.
> >     The diffs:
> >     http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1629&view=revision
> >     http://arthurdejong.org/viewvc/nss-pam-ldapd?revision=1648&view=revision
> >     svn diff -c 1629 http://arthurdejong.org/svn/nss-pam-ldapd
> 
> That seems gratious and is IMHO not suitable.

Actually, this is the better part of the fix for this problem IMO.

The problem was that only the first part of the string was logged. If
the search was very long it would log:
  pam_authz_search "very log string that will eventually be cut off....
The increase in buffer size ensures that the cut-off is later but some
syslog implementations have also been known to have a limited length for
log messages.

This change also ensures that the core of the message (that the filter
is invalid) is at the front of the log message.

The only downside I see from this is that if you have log filtering
rules that pick up on this they will have to be changed. However, this
error message should only appear if you make specific configuration
errors in /etc/nslcd.conf.

Thanks for reviewing!

-- 
-- arthur - adejong@debian.org - http://people.debian.org/~adejong --

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: