Re: [PATCH] increase filter_buffer size in try_autzsearch

[Chris J Arges <chris.j.arges [at] canonical.com>]

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

On 03/16/2012 03:22 AM, Arthur de Jong wrote:
> On Thu, 2012-03-15 at 10:19 -0500, Chris J Arges wrote:
>> Attached is a patch that addresses a bug described in: 
>> https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/951343
>>
>>
>> 
The filter_buffer in try_autzsearch in nslcd/pam.c currently is 1024
>> bytes in length. By increasing this array size, larger search
>> filters can be used.
>> 
>> Let me know if this is the right approach, or if a better
>> technique is needed to fix the situation described in the bug.
> 
> As I understand the bug report the problem was that there was no
> clear error logged when the try_autzsearch failed due to a long
> search filter. The logged error was: pam_authz_search "..." is
> invalid and if ... was very long the line would be cut short and
> the is invalid would be lost. In r1628 I've changed the log message
> to invalid pam_authz_search "...." which means that the core of the
> log message will still be intact even if the line ends up being too
> long.
> 
> Allowing bigger filters is certainly a possibility but not really
> the issue at this point. If someone can come up with a practical
> search that will not fit in the buffer I'll increase it.
> 

A generalized example of a larger buffer would the following:

Since the pam_authz_search filter takes the following form:
(&(sAMAccountName=$username)(|(|...|(memberOf=<group_specN>))...(memberOf=<group_spec2>))(memberOf=<group_spec1>)))

where the <group_spec1> ... <group_specN> values refer to LDAP served
groups and are specified as follows:

CN=<group_name>,OU=Groups,DC=<dc1>,DC=<dc2>

The <group_name> values vary in length from ~10 to ~24 characters
long, meaning that each <group_specX> entry varies in length between
~50 and ~64 characters, which effectively limits the pam_authz_search
filter expression to only supportting between 15 and 20 or so groups
when they are specified in this fashion.

In use cases where there are a larger number of groups, this is limiting.

Let me know if there is a better way to accomplish this.
Thanks,
- --chris j arges
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPa0RdAAoJEPNFAiJniEz2978IANgKMU9Bn/dLf0reUY+c7Jn8
49HgR1ymKZNinsNHX2RuydnxEddgf6jWDtNqC0XwHWPPXyj1i5sun7hMsQMKNg5Y
T1fJpwikU34YOeDcK3xOWrjo4LU8y7UJTHsYFFG4SrNKtFIe50GxbOUo47yr/yGV
cgkcAP3CyDSeaIIeidNgQIHAYJDENFd21EEG34rG48Gs3IuSYD7mCY1x2cTDk/5N
Vc0TgO1LO5gz5TOH80FurSx6Lxz9oemOWmovJyzn5uUG4byiS4/kFgsWEd0G0+uo
7H/7Q4OlvWskEDtAiH5gd+0E22LH4Bghkk/uYv3aRf9KOQpk25/KHqISx0ZzSAU=
=tzKS
-----END PGP SIGNATURE-----
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/