Files in C:\ProgramData\boost_interprocess are not accessible.

[Andreas Neustifter <andreas.neustifter@…>]

When a service running as "Local System" user is using managed_shared_memory the file used for that shared memory is created in C:\ProgramData\boost_interprocess\*\*.

The permissions for this file are such that a regular user starting a process that wants to access that shared memory is not able to access the file and thus access the shared memory.

[Andreas Neustifter <andreas.neustifter@…>]

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]

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

[Andreas Neustifter <andreas.neustifter@…>]

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@…]

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@…]

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.

[Andreas Neustifter <andreas.neustifter@…>]

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]

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.

[Andreas Neustifter <andreas.neustifter@…>]

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]

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@…]

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@…]

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]

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@…]

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]

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]

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]

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