Opened 9 years ago

Last modified 6 years ago

#8581 new Bugs

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

Reported by: Andreas Neustifter <andreas.neustifter@…> Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.50.0 Severity: Problem
Keywords: Cc:

Description

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.

Change History (16)

comment:1 by Andreas Neustifter <andreas.neustifter@…>, 9 years ago

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

comment:2 by Ion Gaztañaga, 9 years ago

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

comment:3 by Andreas Neustifter <andreas.neustifter@…>, 9 years ago

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.

comment:4 by boost.tim-nospam@…, 9 years ago

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.

comment:5 by boost.tim-nospam@…, 9 years ago

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.

in reply to:  4 comment:6 by Andreas Neustifter <andreas.neustifter@…>, 9 years ago

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.

comment:7 by anonymous, 9 years ago

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.

in reply to:  7 comment:8 by Andreas Neustifter <andreas.neustifter@…>, 9 years ago

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...)

comment:9 by Ion Gaztañaga, 9 years ago

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.

comment:10 by boost.tim-nospam@…, 9 years ago

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.

in reply to:  10 comment:11 by andreas.neustifter@…, 9 years ago

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".

comment:12 by Ion Gaztañaga, 9 years ago

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.

in reply to:  12 comment:13 by andreas.neustifter@…, 9 years ago

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...

comment:14 by anonymous, 9 years ago

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?

comment:15 by anonymous, 6 years ago

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

Note: See TracTickets for help on using tickets.