Boost C++ Libraries: Ticket #9321: named mutex permissions are not reset after application crash https://svn.boost.org/trac10/ticket/9321 <p> <strong>Using boost named_mutex on Windows with the standard permissions object.</strong> </p> <p> 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. </p> <p> 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". </p> <p> This is due to the fact that the mutex file in the folder <code>c:\ProgramData\boost_interprocess</code> still exists, and it has the permissions of the user that started the application first. </p> <p> <strong>How to reproduce</strong> </p> <p> The following simple application simulates a crash by exiting before removing the mutex. </p> <p> Run the application as user x. The mutex is successfully constructed, the application crashes unexpectedly. </p> <p> Then run the application as user y. The mutex cannot be constructed as file <code>c:\ProgramData\boost_interprocess\my_mutex_name</code> is still present and cannot be opened by user y although user x who owns the file does not use it by any process. </p> <pre class="wiki">#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&amp; ex) { printf("mutex construction failed: %s\n", ex.what()); } exit(0); boost::interprocess::named_mutex::remove("my_mutex_name"); return 0; } </pre> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/9321 Trac 1.4.3 Ion Gaztañaga Wed, 30 Oct 2013 20:50:12 GMT <link>https://svn.boost.org/trac10/ticket/9321#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/9321#comment:1</guid> <description> <p> 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.. </p> <p> 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. </p> </description> <category>Ticket</category> </item> </channel> </rss>