named mutex permissions are not reset after application crash

[Marcus Ackermann <Marcus.Ackermann@…>]

Using boost named_mutex on Windows with the standard permissions object.

An application creates a named mutex and removes it on exit. This works fine even if the application is started by different users one after the other.

Now assume the application crashes and does not call remove, anymore. When a different user starts the same application later on, the named mutex cannot be created and throws an interprocess exception "access denied".

This is due to the fact that the mutex file in the folder c:\ProgramData\boost_interprocess still exists, and it has the permissions of the user that started the application first.

How to reproduce

The following simple application simulates a crash by exiting before removing the mutex.

Run the application as user x. The mutex is successfully constructed, the application crashes unexpectedly.

Then run the application as user y. The mutex cannot be constructed as file c:\ProgramData\boost_interprocess\my_mutex_name is still present and cannot be opened by user y although user x who owns the file does not use it by any process.

#include "boost/interprocess/sync/named_mutex.hpp"

int main(const int argc, const char* const * const argv)
{
    try
    {
        boost::interprocess::named_mutex mutex(boost::interprocess::open_or_create, "my_mutex_name");

        printf("mutex construction successful\n");
    }
    catch (const boost::interprocess::interprocess_exception& ex)
    {
        printf("mutex construction failed: %s\n", ex.what());
    }

    exit(0);

    boost::interprocess::named_mutex::remove("my_mutex_name");

    return 0;
}

[Ion Gaztañaga]

The behavior is not a bug, as the mutex is still there until you explicitly remove it (POSIX lifetime semantics). It's similar to files. A process can create a file but the second process might not have permissions to remove it. It might not be similar to Windows native reference-counted resources (when the last process holding the resource dies the resources is freed by the OS), but it's not a bug..

If you need to share the mutex between processes you should put the appropriate permissions in the object (like the ones you need if you create a file). You can use unrestricted permissions instead of standard permissions if that doesn't cause security problems in your application.