Boost C++ Libraries: Ticket #8581: Files in C:\ProgramData\boost_interprocess are not accessible.

Tue, 04 Jun 2013 18:13:28 GMT

Is there anything I can assist with? How likely will this be fixed, is it an actual bug or a "feature"? Thanks!

Ion Gaztañaga — Tue, 04 Jun 2013 20:13:45 GMT

Soon to be release Boost 1.54 has changed the folder where the file will be created but I don't think it will fix this bug. You can test the Release Candidate:

http://sourceforge.net/projects/boost/files/boost/1.54.0.beta.1/

to see if the problem is still there so we can concentrate on the last version. Thanks

Thu, 13 Jun 2013 14:04:33 GMT

As you suspected the problem is still there. I have a test setup now that reproduces the error pretty good. I can test future releases for this issue.

boost.tim-nospam@… — Mon, 30 Sep 2013 22:51:05 GMT

This is failing because the Boost library is unable to write to this file: C:\ProgramData\boost_interprocess\application.sh_client_log

The NTFS permissions are set on this folder by the *first person* to run the app. The permissions allow the initial CREATOR full control, however no-one else can modify the file afterwards.

These permissions are Windows default and are not unique to our workstations.

WORKAROUND:
An administrator should delete the C:\ProgramData\boost_interprocess folder from the machine before each new user launches the application.

boost.tim-nospam@… — Mon, 30 Sep 2013 22:59:42 GMT

ALTERNATIVE WORKAROUND:
An administrator should manually remove and reset the permissions on the C:\ProgramData?\boost_interprocess folder.

1) Delete the C:\ProgramData?\boost_interprocess folder from the machine
2) Create a new C:\ProgramData?\boost_interprocess folder
3) Grant Localmachine\Users Modify rights to the C:\ProgramData?\boost_interprocess folder, subfolders and files.

Wed, 02 Oct 2013 20:01:30 GMT

Replying to boost.tim-nospam@…:

This is failing because the Boost library is unable to write to this file: C:\ProgramData\boost_interprocess\application.sh_client_log

The NTFS permissions are set on this folder by the *first person* to run the app. The permissions allow the initial CREATOR full control, however no-one else can modify the file afterwards.

These permissions are Windows default and are not unique to our workstations.

Yes, that is what we see too. In our case a service running as "Local Service" user creates the file, then regular users can not access it.

Replying to boost.tim-nospam@…:

ALTERNATIVE WORKAROUND:
An administrator should manually remove and reset the permissions on the C:\ProgramData?\boost_interprocess folder.

1) Delete the C:\ProgramData?\boost_interprocess folder from the machine
2) Create a new C:\ProgramData?\boost_interprocess folder
3) Grant Localmachine\Users Modify rights to the C:\ProgramData?\boost_interprocess folder, subfolders and files.

Ah, nice, I will try that.

anonymous — Thu, 10 Oct 2013 03:05:41 GMT

One suggestion is to provide an interface that we can specify the folder name instead of "boost_interprocess".

Doing so we can have another workaround, just need to give a unique folder name.

Thu, 10 Oct 2013 05:50:46 GMT

Replying to anonymous:

One suggestion is to provide an interface that we can specify the folder name instead of "boost_interprocess".

Doing so we can have another workaround, just need to give a unique folder name.

The folder name is not the problem, in this folder for each named shared memory a different file is created. The problem is with windows file permissions and who creates the folder. See the relevant technet articles for details. (Can't post links currently since Trac won't let me...)

Ion Gaztañaga — Sun, 13 Oct 2013 18:51:03 GMT

Sorry for not replying earlier. At least in the latest Inteprocess versions the folder is created without any permissiones (which might be a security problem as anyone could take ownership of that folder).

I'm not an expert on Windows file permissions so any help with correct permissions for the folder will be appreciated.

boost.tim-nospam@… — Wed, 06 Nov 2013 03:23:06 GMT

Automating the Alternative Workaround

Execute the following commands to remove, recreate and secure the directory. This will grant "Authenticated Users" access to modify all files and folders within the C:\programdata\boost_interprocess directory.

RD "C:\ProgramData\boost_interprocess" /S /Q
MD "C:\ProgramData\boost_interprocess"
icacls "C:\programdata\boost_interprocess" /inheritance:e /grant:r "Authenticated Users":(OI)(CI)M

Root-Cause Fix

In my opinion, the solution to this issue is to have the Interprocess library write its files to the %TEMP% directory of whichever user account is executing the library. This directory should always allow the user Full Control.

andreas.neustifter@… — Wed, 06 Nov 2013 10:53:15 GMT

Replying to boost.tim-nospam@…:

Root-Cause Fix

In my opinion, the solution to this issue is to have the Interprocess library write its files to the %TEMP% directory of whichever user account is executing the library. This directory should always allow the user Full Control.

This is not a good idea AFAIK: the folder has to be the same for everyone on the system since its needed to provide interprocess communication (between ALL processes). %TEMP% might be different for different users, especially for services started as "Local Service".

Ion Gaztañaga — Wed, 06 Nov 2013 20:46:54 GMT

Another option is to avoid creating a subdirectories and create files at "C:\ProgramData". Permissions for files in that directory are well-known and if anyone needs to modify them, it should pass the appropriate security parameter.

andreas.neustifter@… — Thu, 07 Nov 2013 08:40:02 GMT

Replying to igaztanaga:

Another option is to avoid creating a subdirectories and create files at "C:\ProgramData". Permissions for files in that directory are well-known and if anyone needs to modify them, it should pass the appropriate security parameter.

This would mean "spamming" this folder with all sorts of files, I still like that its in a common folder (boost_interprocess), thing is that this folder and the subfolders within have to be created with proper permissions...

anonymous — Mon, 24 Feb 2014 14:52:19 GMT

IMHO the right solution is to grant unrestricted access to IPC objects:

using namespace boost::interprocess;
permissions unrestricted;
unrestricted.set_unrestricted();
named_mutex mutex(open_or_create, "abc", unrestricted);
scoped_lock< named_mutex > lock(mutex);

There is only one trouble: IPC files can be unexpectedly locked by someone else. When somebody lock the %PROGRAMDATA%\boost_interprocess\abc file the code written above will misbehave on mutex constructor. I do not know how to check the fact: do we have access to IPC file?

anonymous — Wed, 07 Sep 2016 07:27:08 GMT

Has there been any progress with this issue? Any plans to provide a way to setup a custom directory for boost_interprocess files?

Ion Gaztañaga — Wed, 07 Sep 2016 20:11:16 GMT

You can define

BOOST_INTERPROCESS_SHARED_DIR_PATH

as explained in the documentation:

http://www.boost.org/doc/libs/1_61_0/doc/html/interprocess/acknowledgements_notes.html#interprocess.acknowledgements_notes.notes_windows.notes_windows_shm_folder