zones(5) - Solaris application containers



  • Standards, Environments, and Macros                                   zones(5)
    
    
    
    NAME
           zones - Solaris application containers
    
    DESCRIPTION
           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)
           or sshd(1M).
    
    
           The  autobooting of zones is enabled and disabled by the zones service,
           identified by the FMRI:
    
    
           svc:/system/zones:default
    
    
           See zoneadm(1M). Note that a zone has an autoboot property,  which  can
           be set to true (always autoboot). However, if the zones service is dis-
           abled, autoboot will not occur, regardless of the setting of the  auto-
           boot  property  for a given zone. During a clean shutdown of the global
           zone, this service shuts down, halts, or suspends each zone,  depending
           on its autoshutdown property. See zonecfg(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 stable storage.
    
    
           INCOMPLETE
    
               Indicates that the zone is in the midst of being installed or unin-
               stalled, or was interrupted 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 estab-
               lished. For instance, file systems have been mounted, devices  have
               been  configured,  but  no  processes associated with the zone have
               been started.
    
    
           RUNNING
    
               Indicates that user processes associated with the zone  application
               environment are running.
    
    
           SHUTTING_DOWN
           DOWN
    
               Indicates  that the zone is being halted. The zone can become stuck
               in one of these states if it is unable to tear down the application
               environment state (such as mounted file systems) or if some portion
               of the virtual platform cannot be  destroyed.  Such  cases  require
               operator intervention.
    
    
           UNAVAILABLE
    
               Indicates  that the zone has been installed but cannot be booted. A
               zone enters the  unavailable  state  when  the  zone's  storage  is
               unavailable while svc:/system/zones:default is onlining or when the
               zone tries to boot; when  archive-based  installations  fail  after
               successful  archive  extraction;  and  when  the zone's software is
               incompatible with the global zone's  software,  such  as  after  an
               improper forced attach.
    
    
       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.
    
       Privilege Restrictions
           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).
    
       Device Restrictions
           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.
    
       Brands
           A zone can be assigned a brand when it is initially created. A  branded
           zone  is  one  whose software does not match that software found in the
           global zone. The software can include Solaris  software  configured  or
           laid out differently. The particular collection of software is called a
           "brand" (see brands(5)). Once installed, a  zone's  brand  can  not  be
           changed unless the zone is first uninstalled. The solaris-kz brand pro-
           vides even more flexibility, altering many  of  the  restrictions  men-
           tioned in here.
    
       File Systems
           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.
    
    
           ZFS  datasets  that  are  delegated  to a zone are managable within the
           zone. Within a  delegated  dataset,  child  datasets  can  be  created.
           Datasets  that  are  created  within a delegated dataset are themselves
           delegated. Delegated  datasets  other  than  the  top  level  delegated
           dataset  can  be destroyed. Most, but not all, properties can be set on
           delegated datasets. See zfs(1M) for details.
    
    
           Each zone has a top-level delegated dataset, which in turn contains the
           ROOT   and   potentially   other   datasets   such  as  .../export  and
           .../export/home. Datasets that exist under the ROOT dataset make up the
           zone's  boot  environment(s).  Boot environment datasets should only be
           created or destroyed using the zoneadm(1M) or beadm(1M) commands.
    
       Networking
           A zone has its own port number space for TCP, UDP,  and  SCTP  applica-
           tions and typically one or more separate IP addresses (but some config-
           urations of Trusted Extensions share IP address(es) between zones).
    
    
           For the IP layer (IP routing, ARP, IPsec, IP Filter, and so on) a  zone
           can  either  share  the configuration and state with the global zone (a
           shared-IP zone), or have its distinct IP layer configuration and  state
           (an exclusive-IP zone).
    
    
           If  a  zone is to be connected to the same datalink, that is, be on the
           same IP subnet or subnets as the global zone, then  it  is  appropriate
           for the zone to use the shared IP instance.
    
    
           If  a  zone  needs  to  be isolated at the IP layer on the network, for
           instance being connected to different VLANs or different LANs than  the
           global  zone and other non-global zones, then for isolation reasons the
           zone should have its exclusive IP.
    
    
           A shared-IP zone is prevented from doing  certain  things  towards  the
           network  (such as changing its IP address or sending spoofed IP or Eth-
           ernet packets), but an exclusive-IP zone has  more  or  less  the  same
           capabilities  towards  the network as a separate host that is connected
           to the same network interface. In particular, the superuser in  such  a
           zone can change its IP address and spoof ARP packets.
    
    
           The  shared-IP  zones  are assigned one or more network interface names
           and IP addresses in zonecfg(1M). The  network  interface  name(s)  must
           also be configured in the global zone.
    
    
           The exclusive-IP zones are assigned one or more network interface names
           in  zonecfg(1M).  The  network  interface  names  must  be  exclusively
           assigned  to  that  zone,  that is, it (or they) can not be assigned to
           some other running zone, nor can they be used by the global zone.
    
    
           The full IP-level functionality in the form of DHCP client,  IPsec  and
           IP  Filter,  is  available  in  exclusive-IP zones and not in shared-IP
           zones.
    
       Host Identifiers
           A zone is capable of emulating a 32-bit host identifier, which  can  be
           configured via zonecfg(1M), for the purpose of system consolidation. If
           a zone emulates a host identifier, then commands such as hostid(1)  and
           sysdef(1M) as well as C interfaces such as sysinfo(2) and gethostid(3C)
           that are executed within the context of the zone will display or return
           the  zone's  emulated  host  identifier  rather than the host machine's
           identifier.
    
       Logging
           The output of the  zone's  console  is  logged  to  /var/log/zones/con-
           sole.<zonename>.    Other    runtime    information    is   logged   to
           /var/log/zones/messages.<zonename>. Each log  is  rotated  periodically
           using logadm(1M).
    
       Live Zone Reconfiguration
           You  can  reconfigure  a running zone without needing to reboot it. You
           can also inspect live configuration  of  a  running  zone.  zonecfg(1M)
           allows  to  retrieve  and  inspect the live configuration, make desired
           changes, and temporarily apply them to the  running  zone.  zonecfg(1M)
           allows  to reconfigure the running zone persistently based on the saved
           zone configuration. For more information, see zonecfg(1M).
    
    
           The zone configuration consists of resources  and  resource  properties
           defined  in  the  zonecfg(1M) manual page. For the purpose of live zone
           reconfiguration,  only  resources  and  resource  properties  known  to
           zonecfg(1M),  which are also permitted by the associated brand are sup-
           ported.
    
    
           See brand specific manual pages for the list of resources and  resource
           properties  supported by the live zone reconfiguration for the selected
           brand. However, there are restrictions which apply to all brands.
    
    
           The following resources and resource properties are  not  supported  by
           the live zone reconfiguration for all brands:
    
             brand
             zonename
             zonepath
             ip-type
             rootzpool
    
    
    
           Any  changes  made to the listed resources and resource properties will
           cause the live zone reconfiguration fail if they  are  applied  to  the
           running zone.
    
    
           The  resources  and  resource properties listed below do not affect the
           running zone directly. For this reason, you can modify them in the per-
           sistent  configuration at any time. But, any attempts to change them in
           the live configuration will be refused. This applies to all brands.
    
             admin
             attr
             autoboot
             autoshutdown
             bootargs
             suspend
    
    
    ATTRIBUTES
           See attributes(5) for descriptions of the following attributes:
    
    
    
    
           +-----------------------------+-----------------------------+
           |      ATTRIBUTE TYPE         |      ATTRIBUTE VALUE        |
           +-----------------------------+-----------------------------+
           |Availability                 |system/zones                 |
           +-----------------------------+-----------------------------+
    
    SEE ALSO
           hostid(1),   zlogin(1),   zonename(1),    beadm(1M),    in.rlogind(1M),
           logadm(1M), solaris-kz(5),  sshd(1M), sysdef(1M), zfs(1M), zoneadm(1M),
           zonecfg(1M),  kill(2),  priocntl(2),  sysinfo(2),  gethostid(3C),  get-
           zoneid(3C),  ucred_get(3C),  proc(4),  attributes(5), brands(5), privi-
           leges(5), crgetzoneid(9F)
    
    
    
    SunOS 5.11                        9 Apr 2015                          zones(5)
    


© Lightnetics 2024