zones(5) Standards, Environments, and Macros zones(5)
zones - Solaris application containers
The zones facility in Solaris provides an isolated environment for run-
ning applications. Processes running in a zone are prevented from moni-
toring or interfering with other activity in the system. Access to
other processes, network interfaces, file systems, devices, and inter-
process communication facilities are restricted to prevent interaction
between processes in different zones.
The privileges available within a zone are restricted to prevent opera-
tions with system-wide impact. See privileges(5).
You can configure and administer zones with the zoneadm(1M) and
zonecfg(1M) utilities. You can specify the configuration details a
zone, install file system contents including software packages into the
zone, and manage the runtime state of the zone. You can use the zlo-
gin(1) to run commands within an active zone. You can do this without
logging in through a network-based login server such as in.rlogind(1M)
An alphanumeric name and numeric ID identify each active zone. Alphanu-
meric names are configured using the zonecfg(1M) utility. Numeric IDs
are automatically assigned when the zone is booted. The zonename(1)
utility reports the current zone name, and the zoneadm(1M) utility can
be used to report the names and IDs of configured zones.
A zone can be in one of several states:
CONFIGURED Indicates that the configuration for the zone
has been completely specified and committed to
INCOMPLETE Indicates that the zone is in the midst of
being installed or uninstalled, or was inter-
rupted in the midst of such a transition.
INSTALLED Indicates that the zone's configuration has
been instantiated on the system: packages have
been installed under the zone's root path.
READY Indicates that the "virtual platform" for the
zone has been established. Network interfaces
have been plumbed, file systems have been
mounted, devices have been configured, but no
processes associated with the zone have been
RUNNING Indicates that user processes associated with
the zone application environment are running.
SHUTTING_DOWN Indicates that the zone is being halted. The
DOWN zone can become stuck in one of these states if
it is unable to tear down the application envi-
ronment state (such as mounted file systems) or
if some portion of the virtual platform cannot
be destroyed. Such cases require operator
Process Access Restrictions
Processes running inside a zone (aside from the global zone) have
restricted access to other processes. Only processes in the same zone
are visible through /proc (see proc(4) or through system call inter-
faces that take process IDs such as kill(2) and priocntl(2). Attempts
to access processes that exist in other zones (including the global
zone) fail with the same error code that would be issued if the speci-
fied process did not exist.
Processes running within a non-global zone are restricted to a subset
of privileges, in order to prevent one zone from being able to perform
operations that might affect other zones. The set of privileges limits
the capabilities of privileged users (such as the super-user or root
user) within the zone. The list of privileges available within a zone
can be displayed using the ppriv(1) utility. For more information about
privileges, see privileges(5).
The set of devices available within a zone is restricted, to prevent a
process in one zone from interfering with processes in other zones. For
example, a process in a zone should not be able to modify kernel memory
using /dev/kmem, or modify the contents of the root disk. Thus, by
default, only a few pseudo devices considered safe for use within a
zone are available. Additional devices can be made available within
specific zones using the zonecfg(1M) utility.
The device and privilege restrictions have a number of effects on the
utilities that can run in a non-global zone. For example, the eep-
rom(1M), prtdiag(1M), and prtconf(1M) utilities do not work in a zone
since they rely on devices that are not normally available.
Each zone has its own section of the file system hierarchy, rooted at a
directory known as the zone root. Processes inside the zone can access
only files within that part of the hierarchy, that is, files that are
located beneath the zone root. This prevents processes in one zone from
corrupting or examining file system data associated with another zone.
The chroot(1M) utility can be used within a zone, but can only restrict
the process to a root path accessible within the zone.
In order to preserve file system space, sections of the file system
can be mounted into one or more zones using the read-only option of the
lofs(7FS) file system. This allows the same file system data to be
shared in multiple zones, while preserving the security guarantees sup-
plied by zones.
NFS and autofs mounts established within a zone are local to that zone;
they cannot be accessed from other zones, including the global zone.
The mounts are removed when the zone is halted or rebooted.
Zones can be assigned logical network interfaces, which can be used to
communicate over the network. These interfaces are configured using the
zonecfg(1M) utility. The interface is removed when the zone is halted
or rebooted. Only logical interfaces can be assigned to a zone.
See attributes(5) for descriptions of the following attributes:
tab() allbox; cw(2.750000i)| cw(2.750000i) lw(2.750000i)|
lw(2.750000i). ATTRIBUTE TYPEATTRIBUTE VALUE AvailabilitySUNWcsu
zlogin(1), zonename(1), in.rlogind(1M), sshd(1M), zoneadm(1M),
zonecfg(1M), getzoneid(3C), kill(2), priocntl(2), ucred_get(3C), get-
zoneid(3C), proc(4), attributes(5), privileges(5), crgetzoneid(9F)
SunOS 5.10 13 Apr 2004 zones(5)