virtualcam: Grant ALL_APP_PACKAGES read access to shared memory#13197
virtualcam: Grant ALL_APP_PACKAGES read access to shared memory#13197aarumug wants to merge 1 commit intoobsproject:masterfrom
Conversation
AppContainer processes (e.g. Microsoft Teams) cannot open kernel objects that have a default DACL, because the implicit integrity-level check blocks low-IL AppContainer tokens even when the object owner is the same user. The OBS virtual camera's only IPC primitive is the named file mapping `OBSVirtualCamVideo`. When Teams (running in a low-IL AppContainer) instantiates the OBS DirectShow filter in-process and calls `OpenFileMappingW(FILE_MAP_READ, ...)`, the call fails with ACCESS_DENIED because the mapping was created with a NULL security descriptor, which does not include an ACE for `ALL_APP_PACKAGES` (S-1-15-2-1). Fix: set an explicit DACL on `CreateFileMappingW` that adds `GENERIC_READ | GENERIC_EXECUTE` for `S-1-15-2-1` (ALL_APP_PACKAGES). This covers every AppContainer regardless of container identity. The DACL also preserves full access for the creator owner and Local System, and read/execute for Everyone (matching the effective default for normal processes), so existing non-AppContainer consumers are unaffected. No other changes are required: HKCR is readable from AppContainers, the installed DLL has Program Files ACLs that already include ALL_APP_PACKAGES, and all synchronisation is done through volatile fields inside the shared memory with no external kernel objects. Use Windows SDK 10.0.26100.0
|
Please properly fill out the PR template. |
I've filled out a few things. Will update more as I keep testing in different machines. |
|
@Fenrirthviti - why is the PR closed? |
|
This PR contains what appears to be, as an educated guess, an AI-generated document that doesn't have any place in the repo. Was this PR developed using LLM tooling? |
Yes, the PR was developed using LLM. I used it to discover and understand the codebase and the architecture. To clarify, the fix itself is not an educated guess. I did test this fix by building win-dshow.dll, integrating it in Microsoft Teams and tested the OBS virtual camera feature modification that I'm working on. OBS virtual camera was not working when the component that uses it, is moved into an appcontainer. With this fix it works as expected. I agree that the generated .md file doesn’t belong in the repo. Those were the notes while I was understanding the code and I thought it might be useful context, but I’m happy to take it out. If there are concerns about the change itself, I’d appreciate feedback directly on the PR so we can discuss them there. |
|
Also, please point me to any documentation that you have on the kind of manual testing that needs to be done. I want to make sure that this change doesn't cause any regression. |
|
We do not accept AI-generated PRs. Additionally, we tested and were unable to replicate the issue as stated here. Thank you for the submission. |
|
Can you please share the test you did? Was the component consuming win-dshow.dll is running in low IL appcontainer and was able to read the shared memory created by OBS studio? |
|
Thanks for the AI policy pointer. I wasn't aware of that. I'll rework the PR and submit. But please share the test you did. Because for the feature I am working on in Teams OBS studio virtual camera doesn't work. I will share a self contained test program demonstrating the problem. |
|
In the future, please do not submit a PR with an incomplete checklist, without reading the project's contribution policies and processes. There is a reason that is in the template, and PR should not be submitted until all the basic checkboxes are complete. Tests were performed using Teams on Windows 10 and 11. Windows 10 did not have issues, but on Windows 11, the initial attempt to access the camera failed, but switching away from devices and back to the devices tab allowed it work so we're not entirely sure that is a related issue, but things worked just fine there. However, discussion indicates that this should be at least a conceptually correct fix (and we have done something similar in the past) The recommend fix from those discussions was to use user ACL + AppContainer access, so other system users cannot open the handles. If this is reworked and submitted without the use of AI tooling, we can consider it. |
2 participants
Description
Processes AppContainer cannot open kernel objects that have a default DACL, because the implicit integrity-level check blocks low-IL AppContainer tokens even when the object owner is the same user.
The OBS virtual camera's only IPC primitive is the named file mapping
OBSVirtualCamVideo. When Teams (running in a low-IL AppContainer) instantiates the OBS DirectShow filter in-process and callsOpenFileMappingW(FILE_MAP_READ, ...), the call fails with ACCESS_DENIED because the mapping was created with a NULL security descriptor, which does not include an ACE forALL_APP_PACKAGES(S-1-15-2-1).Fix: set an explicit DACL on
CreateFileMappingWthat addsGENERIC_READ | GENERIC_EXECUTEforS-1-15-2-1(ALL_APP_PACKAGES). This covers every AppContainer regardless of container identity. The DACL also preserves full access for the creator owner and Local System, and read/execute for Everyone (matching the effective default for normal processes), so existing non-AppContainer consumers are unaffected.No other changes are required: HKCR is readable from AppContainers, the installed DLL has Program Files ACLs that already include ALL_APP_PACKAGES, and all synchronisation is done through volatile fields inside the shared memory with no external kernel objects.
Use Windows SDK 10.0.26100.0
Motivation and Context
OBS studio cannot be used as virtual camera from an app running in appcontainer. This PR fixes that.
N/A
N/A
How Has This Been Tested?
Install OBS Studio version 32.0.4
Build win-dshow.dll from my changes and placed it in C:\Program Files\obs-studio\obs-plugins\64bit folder and started OBS studio.
Latest Windows 11 build on a Dell Optiplex machine with a logitech camera.
Types of changes
Checklist: