On Wed, Aug 22, 2012 at 03:23:16PM -0700, Howard Chu wrote:

cmikk@qwest.net 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 root.

7: slapd fails startup.

Thanks,