Sharing named objects

This topic explains how to share named objects between Universal Windows Platform (UWP) applications and Win32 applications.

Named objects in packaged applications

Named objects provide an easy way for processes to share object handles. After a process has created a named object, other processes can use the name to call the appropriate function to open a handle to the object. Named objects are commonly used for thread synchronization and interprocess communication.

By default, packaged applications can only access named objects they've created. In order to share named objects with packaged applications, permissions must be set when objects are created, and names must be qualified when objects are opened.

Creating named objects

Named objects are created with a corresponding Create API:

• CreateEvent
• CreateFileMapping
• CreateMutex
• CreateSemaphore
• CreateWaitableTimer

All of these APIs share an LPSECURITY_ATTRIBUTES parameter which enables the caller to specify access control lists (ACLs) to control what processes can access the object. In order to share named objects with packaged applications, permission must be granted within the ACLs when the named objects are created.

Security identifiers (SIDs) represent identities within ACLs. Every packaged application has its own SID based on its package family name. You can generate the SID for a packaged application by passing its package family name to DeriveAppContainerSidFromAppContainerName.

Note

The package family name can be found via the package manifest editor in Visual Studio during development time, via Partner Center for applications published through the Microsoft Store, or via the Get-AppxPackage PowerShell command for applications that are already installed.

This sample demonstrates the basic pattern needed to ACL a named object. To share named objects with packaged applications, build an EXPLICIT_ACCESS structure for each application:

• grfAccessMode = GRANT_ACCESS
• grfAccessPermissions = appropriate permissions based on the object and intended usage
  • Generic Access Rights
  • Synchronization Object Security and Access Rights
  • File Mapping Security and Access Rights
• grfInheritance = NO_INHERITANCE
• Trustee.TrusteeForm = TRUSTEE_IS_SID
• Trustee.TrusteeType = TRUSTEE_IS_USER
• Trustee.ptstrName = the SID acquired from DeriveAppContainerSidFromAppContainerName

By populating the LPSECURITY_ATTRIBUTES parameter in Create calls with EXPLICIT_ACCESS rules for packaged applications, you can grant access to those applications to open the named object.

Note

Win32 applications can access all named objects created by packaged applications as long as they qualify the object names when opening them. They do not need to be granted access.

Opening named objects

Named objects are opened by passing a name to a corresponding Open API:

• OpenEvent
• OpenFileMapping
• OpenMutex
• OpenSemaphore
• OpenWaitableTimer

Named objects created by a packaged application are created within the namespace of the application, otherwise known as the named object path. When opening named objects created by a packaged application, the object names must be prefixed with the creating application's named object path.

GetAppContainerNamedObjectPath will return the named object path for a packaged application based on its SID. You can generate the SID for a packaged application by passing its package family name to DeriveAppContainerSidFromAppContainerName.

Note

The package family name can be found via the package manifest editor in Visual Studio during development time, via Partner Center for applications published through the Microsoft Store, or via the Get-AppxPackage PowerShell command for applications that are already installed.

When opening named objects created by a packaged application, use the format <PATH>\<NAME>:

• Replace <PATH> with the creating application's named object path.
• Replace <NAME> with the object name.

Note

Prefixing object names with <PATH> is only required if a packaged application created the object. Named objects created by Win32 applications do not need to be qualified, though access must still be granted when the objects are created.

Remarks

Named objects in packaged applications are isolated by default to preserve security and ensure support for application lifecycle events like suspension and termination. Sharing named objects across applications introduces tight binding and versioning constraints and requires each application to be resilient to the lifecycle of others. For these reasons, it is recommended to only share named objects between applications from the same publisher.