[Date Prev][Date Next]
Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
- From: firstname.lastname@example.org
- Date: Thu, 23 Aug 2012 19:29:10 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
On Wed, Aug 22, 2012 at 03:23:16PM -0700, Howard Chu wrote:
> email@example.com wrote:
> > For example, if you run slapd as an unprivileged user, stop slapd, and do an
> > offline slapcat as root, slapd will not start up again as that unprivileged
> > user. [snip]
> This sounds like a bug in your platform's sem_open() syscall. If you first
> started slapd as an unprivileged user, the semaphore should be owned by that
> user. Running slapcat as root should not change the semaphore owner uid, and
> the unprivileged owner should still be able to access the semaphore later.
In the scenario described, slapd is not running
when slapcat starts as root, so slapcat gets an
exclusive lock on the lockfile, sem_unlink()s the
semaphores created by the unprivileged slapd user, and
recreates them, now owned by root.
When slapcat finishes, it closes the database and does
not remove the semaphores. When slapd starts up, it
gets an exclusive lock, attempts to sem_unlink() the
semaphores created as (and owned by) root, which fails.
In timeline form:
1: slapcat gets exclusive lock on lock.mdb
2: slapcat (as root) unlinks /MDBrXXXX and /MDBwXXXX
3: slapcat (as root) creates /MDBrXXXX and /MDBwXXXX
4: slapcat exits, releasing lock on lock.mdb, leaving
behind /MDBrXXXX and /MDBwXXXX (owned by root)
5: slapd gets exclusive lock on lock.mdb
6: slapd (as unpriv) unlinks /MDBrXXXX and /MDBwXXXX.
This fails because of the semaphores are owned by
7: slapd fails startup.
Chris Mikkelson | "Unfortunately, simplicity is a complicated mess
firstname.lastname@example.org | of a concept." --Taner Edis