|ZONES(7)||Standards, Environments, and Macros||ZONES(7)|
The privileges available within a zone are restricted to prevent operations with system-wide impact. See privileges(7).
You can configure and administer zones with the zoneadm(8) and zonecfg(8) 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 zlogin(1) to run commands within an active zone. You can do this without logging in through a network-based login server such as sshd(8).
The autobooting of zones is enabled and disabled by the zones service, identified by the FMRI:
See zoneadm(8). Note that a zone has an autoboot property, which can be set to true (always autoboot). However, if the zones service is disabled, autoboot will not occur, regardless of the setting of the autoboot property for a given zone. See zonecfg(8).
An alphanumeric name and numeric ID identify each active zone. Alphanumeric names are configured using the zonecfg(8) utility. Numeric IDs are automatically assigned when the zone is booted. The zonename(1) utility reports the current zone name, and the zoneadm(8) utility can be used to report the names and IDs of configured zones.
A zone can be in one of several states:
The device and privilege restrictions have a number of effects on the utilities that can run in a non-global zone. For example, the eeprom(8), prtdiag(8), and prtconf(8) utilities do not work in a zone since they rely on devices that are not normally available.
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(4FS) file system. This allows the same file system data to be shared in multiple zones, while preserving the security guarantees supplied 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.
A zone can share filesystems using nfs(5) or smb(5) subject to the restrictions earlier in this section, plus the additional restriction that file sharing can only be done from filesystems a zone completely controls. Some brands(7) do not have the zone root set to a filesystem boundary. sharefs(4FS) can instantiate per-zone subject to the brand restrictions.
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 Ethernet 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(8). 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(8). 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.
|May 23, 2021||OmniOS|