Revoking access to a shared memory object

The creator of a shared memory object can revoke another process's mappings of the object.

For example:

Note: This example focuses on resource managers but it also applies to any process that provides a reference to a shared memory object it owns to another process.

Figure 1. Illustration of how the resource manager responds to a devious client's attempt to fool it.

The user interface to support this scenario includes:

a SHMCTL_REVOCABLE flag passed to shm_ctl() that marks a shared memory object as revocable.
a shm_revoke() function that you can use on a revocable object to remove mappings for either one particular process or all processes with mappings to it.

So that a process can't protect against revocation by forking, revocable object regions are marked as MAP_NOINHERIT; the memory maps for these regions won't exist in the child.

For the steps to follow in using revocable shared memory objects, see “Putting it all together: using handles with anonymous, revocable shared memory objects,” below.

The discussion above focuses on the case where the creator of a shared memory object doesn't trust the other process. What about the opposite case, where the other process doesn't trust the creator? The other process could check the object's flags (see the SHMCTL_GET_FLAGS bit for shm_ctl()) and decide not to use the object, or it could access the mapped memory carefully, using sigsetjmp() or a similar mechanism. There's not much the creator and the other process can do if neither trusts the other.