OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6745
Full headers

From: h.b.furuseth@usit.uio.no
Subject: HEAD emfile race condition -> slapd stopping listening?
Compose comment
Download message
State:
0 replies:
3 followups: 1 2 3

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 13 Dec 2010 12:49:00 +0000
From: h.b.furuseth@usit.uio.no
To: openldap-its@OpenLDAP.org
Subject: HEAD emfile race condition -> slapd stopping listening?
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: 
URL: 
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard


In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support:

  slap_listener() protects emfile with slap_daemon[0 ].sd_mutex,
  but slapd_remove() protects it  with slap_daemon[id].sd_mutex.

Maybe to compensate, slapd_remove() has code which checks if emfile
is too big, but nothing checks if it is too small - which looks like
slapd might never start listening again.

Simplest fix: add this to slapd_remove():

   if (id) ldap_pvt_thread_mutex_<lock,unlock>(
&slap_daemon[0].sd_mutex );

slap_daemon[0].sd_mutex looks quite contended that way, though.
Maybe a separate emfile_mutex is better.

Followup 1

Download message
Date: Thu, 23 Dec 2010 16:15:10 -0800
From: Howard Chu <hyc@symas.com>
To: h.b.furuseth@usit.uio.no
CC: openldap-its@openldap.org
Subject: Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support:
>
>    slap_listener() protects emfile with slap_daemon[0 ].sd_mutex,
>    but slapd_remove() protects it  with slap_daemon[id].sd_mutex.
>
> Maybe to compensate, slapd_remove() has code which checks if emfile
> is too big, but nothing checks if it is too small - which looks like
> slapd might never start listening again.
>
> Simplest fix: add this to slapd_remove():
>
>     if (id) ldap_pvt_thread_mutex_<lock,unlock>(&slap_daemon[0].sd_mutex
);
>
> slap_daemon[0].sd_mutex looks quite contended that way, though.
> Maybe a separate emfile_mutex is better.

Alternatively, just skip the check entirely when id != 0. Which would mean 
that only closing a session on the first listener would ever trigger the other 
listeners to be unmuted. Doesn't seem so terrible; if slapd is actually out of 
descriptors one or two connections either way won't make a huge difference in 
service.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Date: Thu, 23 Dec 2010 17:56:10 -0800
From: Howard Chu <hyc@symas.com>
To: h.b.furuseth@usit.uio.no
CC: openldap-its@openldap.org
Subject: Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
Howard Chu wrote:
> h.b.furuseth@usit.uio.no wrote:
>> Full_Name: Hallvard B Furuseth
>> Version: HEAD
>> OS:
>> URL:
>> Submission from: (NULL) (129.240.6.233)
>> Submitted by: hallvard
>>
>>
>> In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support:
>>
>>     slap_listener() protects emfile with slap_daemon[0 ].sd_mutex,
>>     but slapd_remove() protects it  with slap_daemon[id].sd_mutex.
>>
>> Maybe to compensate, slapd_remove() has code which checks if emfile
>> is too big, but nothing checks if it is too small - which looks like
>> slapd might never start listening again.

On 2nd thought - I don't see how the outcome you describe can occur. If emfile 
is non-zero, the list of listeners will be checked for a listener with 
non-zero mute status. If any are found, one is guaranteed to be unmuted. If 
none are found, emfile will be zeroed.

In no case will slapd fail to unmute a listener.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 3

Download message
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Tue, 28 Dec 2010 15:35:48 +0100
To: Howard Chu <hyc@symas.com>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
Howard Chu wrote:
>>h.b.furuseth@usit.uio.no wrote:
>>> Maybe to compensate, slapd_remove() has code which checks if emfile
>>> is too big, but nothing checks if it is too small - which looks
like
>>> slapd might never start listening again.
> 
> On 2nd thought - I don't see how the outcome you describe can occur. If
emfile
> is non-zero, the list of listeners will be checked for a listener with 
> non-zero mute status. If any are found, one is guaranteed to be unmuted. 

But if emfile becomes too small, it reaches zero with a listener still
muted - and with emfile = zero, the nothing is unmuted.

-- 
Hallvard


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org