[SSSD] [PATCH] Handle multiple simultaneous enumeration requests

Stephen Gallagher sgallagh at redhat.com
Thu Sep 2 13:13:24 UTC 2010


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

Simo made some style-related comments on IRC which I have incorporated
into this second version of the patch.

It changes the function declarations so that the return type is on the
same line as the function name, and it moves the assorted tevent_req
functions up in line with the original NSS call, so it reads more naturally.


On 09/01/2010 07:54 PM, Stephen Gallagher wrote:
> On 09/01/2010 07:49 PM, Stephen Gallagher wrote:
>> Simo, ideally I'd like you to do this review, since you're the most
>> familiar with this area of the code. However, other eyes are always
>> encouraged.
> 
>> Previously, if a second enumeration request arrived while one was
>> already being processed, each process would receive only a subset
>> of the total number of available users or groups. This is because
>> we were maintaining the response object as a global value in the
>> NSS responder. The second request would come in, see that the data
>> set was already populated, and start reading from wherever the
>> cursor was currently pointed.
> 
>> With this patch, we now add a reference count to the data set
>> object and move the cursor to the client context instead of the
>> global NSS context.
> 
>> Additionally, this patch completely rewrites the approach to
>> enumerations in the tevent_req style. This makes it much easier to
>> follow in the code.
> 
>> There is a known issue with this patch that I am working to address in a
>> follow-up patch. With this change, it's possible to trick the sssd_nss
>> process into holding onto the enumeration cache forever. Since the
>> global result object is retained as long as there are references to it,
>> it would be possible for a malicious program to call setpwent/getpwent
>> and never call getpwent - thereby preventing the result object from ever
>> being reaped.
> 
>> I will be sending a follow-up patch that adds a timeout value on the
>> lifetime of the result object. The plan will be that once this timeout
>> runs out, the object will be reaped and if there are active enumerations
>> running (meaning that they have started calling getpwent but not
>> retrieved all the entries yet), they will be directed to call another
>> setpwent, but will retain their current pointers to the result data.
>> Since in the 99% case, the data will remain the same (and in the same
>> order), this will have minimal impact on the clients.
> 
>> I am sending the current patch out first so I can get some opinions on
>> the approach while I work on fixing the vulnerability it introduces.
> 
>> This patch addresses https://fedorahosted.org/sssd/ticket/608

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx/ovQACgkQeiVVYja6o6Mp6ACfSGsuaX3nJU/pDfxodVkW0Xqb
vxYAnAiYQVBsLZyhKVgqQyTfF2XLnTKL
=yofS
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Handle-multiple-simultaneous-enumeration-requests.patch
Type: text/x-patch
Size: 44617 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20100902/d466591e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Handle-multiple-simultaneous-enumeration-requests.patch.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20100902/d466591e/attachment.sig>


More information about the sssd-devel mailing list