Section 6.9. Interprocess Communication

6.9. Interprocess Communication

Local interprocess communication (IPC) represents a particular problem for zones, since processes in different (non-global) zones should normally only be able to communicate through network APIs, as would be the case with processes running on separate machines. It might be possible for a process in the global zone to construct a way for processes in other zones to communicate, but this should not be possible without the participation of the global zone. In this section, we look at the different forms of IPC and how this issue is handled for each.

6.9.1. Pipes, STREAMS, and Sockets

IPC mechanisms that use the file system as a rendezvous, for example, pipes (through fifofs), STREAMS (through namefs), and UNIX domain sockets (through sockfs), fit naturally into the zone model without modification since processes in one zone will not have access to file system locations associated with other zones. Since the file system hierarchy is partitioned, there is no way to achieve the rendezvous without the involvement of the global zone (which has access to the entire hierarchy). If processes in different zones are able to communicate, the getpeerucred(3c) interface can determine the credentials (including zone ID) of processes on the other end of the connection.

6.9.2. Doors

Doors also use the file system as a rendezvous (through namefs), so potential door clients will normally only be able to call servers within the same zone. Doors, however, also provide a way of safely supporting cross-zone communication, since the server can retrieve the credentials of the caller by using door_ucred(3door). We have extended the private data structure returned by door_ucred to include a zone ID and have added a cred_getzoneid(3c) interface to retrieve the zone ID from the structure. This allows the creation of truly global door servers if desired; a door server from the global zone could be mounted in each zone, and the server could check whether the caller is authorized to perform a given operation based on its zone ID as well as other credential information. The door-server approach provides a means for doing efficient cross-zone communication with doors when necessary (although we think that most such services should be written with networking interfaces for optimal flexibility and portability). In fact, this functionality is used to implement the per-zone device node creation described in Section 6.8 (allowing processes in each zone to contact the global devfsadmd daemon).

6.9.3. Loopback Transport Providers

The loopback transport providersticlts, ticots, and ticotsordprovide yet another mechanism for IPC. These transports, like traditional network transports such as UDP or TCP, can be accessed through standard transport-independent TLI/XTI interfaces. However, the loopback transports are limited to communication among processes on the same machine and are implemented as pseudo-devices without involving the kernel networking stack. The transport providers support "flex addresses," which are arbitrary sequences of octets of length greater than 0. When zones are in use, the flex address space is partitioned to prevent communication among processes in different zones. In other words, each zone has its own flex address namespace. This is done by internally (within the tl driver) associating zone IDs with transport endpoints, based on the zone ID of the process performing the bind(3socket) call. This means that a process calling connect(3socket) connects only to the endpoint with a matching address associated with the caller's zone. In addition, multiple processes can bind to the same address as long as they are in different zones; this means that multiple applications can use the same address without conflict if they are running in different zones, thereby avoiding the need for cross-zone coordination in address selection.

6.9.4. System V IPC

The System V IPC interfaces allow applications to create persistent objects (shared memory segments, semaphores, and message queues) for communication and synchronization among processes on the same system. The objects are dynamically assigned numeric identifiers that can be associated with user-defined keys, allowing use of a single object in unrelated processes. Objects are also associated with an owner (based on the effective user ID of the creating process unless explicitly changed) and permission flags that can be set to restrict access when desired.

To prevent sharing (intentional or unintentional) among processes in different zones, a zone ID is associated with each object, based on the zone in which the creating process was running at time of creation. Processes running in a zone other than the global zone can only access or control objects associated with the same zone. There are no new restrictions for processes running in the global zone (though the existing user ID-based restrictions will be honored); this allows an administrator in the global zone to manage IPC objects throughout the system without needing to enter each zone. The key namespace is per-zone, which avoids the possibility of key collisions between zones.

The administrative commands, ipcs(1) and ipcrm(1), have been updated with zone-specific options for use when run in the global zone. By default, ipcs reports objects from the current zone. When run in the global zone, however, the -z zone option reports objects from the specified zone, and the -Z option reports objects from all zones, with the zone association of each identified. These options can be used to disambiguate between objects that may have identical keys but are in different zones and in general to provide better observability into the usage of IPC objects within zones.

The ipcrm command similarly operates on objects in the current zone, unless run in the global zone and given the -z zone option. This option removes objects in other zones.

In the past, the System V IPC implementation in Solaris included a number of static systemwide limits on the number of objects that can be created, as well as various details of those objects (maximum size of shared memory segments, maximum depth of message queues, etc.). In a system with zones, this would lead to an obvious problem with processes in one zone exhausting all the available objects. Fortunately, this implementation was recently revised to eliminate the need for these limits (see Section 4.2); the only tunable parameters in the new code are per-project and per-process resource controls, which require no adaptation to work in a zone environment.

6.9.5. POSIX IPC

The POSIX IPC interfaces implemented in librt, unlike the System V interfaces, use files to rendezvous between processes. This means that they fall into the same category as pipes, sockets, and streams, in that no changes are necessary to enforce per-zone isolation and object key namespaces.