Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.

[h.b.furuseth@usit.uio.no]

Howard Chu writes:
>h.b.furuseth@usit.uio.no wrote:
>> This is worse with a database with is intended to be used by
>> different users (A and B):
> (...)
>> mdb_env_setup_locks() can sem_unlink both semaphores before doing
>> anything else, so that reopening a database as root will clean up.
>> Drop the error checks of sem_unlink (so both get called), instead
>> use O_EXCL in sem_open(,O_CREAT,,).  Unless I'm missing something,
>> the error checks just work like an emulation of O_EXCL anyway.
> 
> The sem_unlink() and sem_open() sequence isn't ideal, certainly. I would
> prefer to just use the existing semaphore.

I just realized reusing the semaphores is a security problem:
Anyone who can compute/read the semaphore names, can create the
semaphores owned by themselves and then muck with them to sabotage
someone else's mdb.  I suppose the same goes for SysV semaphores.

I don't know what the accepted way to deal with that is, but I
suggest to unlink + O_EXCL as above for now, document the multi-uid
restriction, and punt the rest until anyone who cares shows up.

> Another possibility is to just use SysV semaphores instead of POSIX
> semaphores. Then you can use the ipcs(1) command to manually cleanup.
> (...)
[later]
> I'm also reminded that there is no defined behavior for SysV
> semaphores in threads, they are only speciried for inter-process
> synchronization. So forget that...

I expect the work-around is to use them for IPC only, and wrap
them in process-local mutexes in the MDB_env for thread sync.

-- 
Hallvard