This chapter covers these general zone administration topics:
Solaris 10 8/07: Networking in Exclusive-IP Non-Global Zones
Fair Share Scheduler on a Solaris System With Zones Installed
Extended Accounting on a Solaris System With Zones Installed
For information on lx branded zones, see Part III, lx Branded Zones.
Solaris 10 1/06: A new section Unmounting File Systems in Zones has been added.
Solaris 10 1/06: New sections on zone backup and restore procedures have been added. See About Backing Up a Solaris System With Zones Installed.
Solaris 10 6/06: A ZFS entry has been added to the table in Mounting File Systems in Zones.
Solaris 10 8/07: The following information is new or updated in this release.
With this release, two IP types are now available for non-global zones. Information on features available by IP type has been added. See Networking in Shared-IP Non-Global Zones and Solaris 10 8/07: Networking in Exclusive-IP Non-Global Zones.
Solaris IP Filter can now be used in shared-IP zones. See Solaris IP Filter in Shared-IP Zones for more information.
Information on privilege settings in zones has been revised. See Table 27–1.
The information in Commands Used on a Solaris System With Zones Installed has been updated.
For a complete listing of new Solaris 10 features and a description of Solaris releases, see Oracle Solaris 10 9/10 What’s New.
The global zone acts as both the default zone for the system and as a zone for system-wide administrative control. There are administrative issues associated with this dual role. Since applications within the zone have access to processes and other system objects in other zones, the effect of administrative actions can be wider than expected. For example, service shutdown scripts often use pkill to signal processes of a given name to exit. When such a script is run from the global zone, all such processes in the system will be signaled, regardless of zone.
The system-wide scope is often needed. For example, to monitor system-wide resource usage, you must view process statistics for the whole system. A view of just global zone activity would miss relevant information from other zones in the system that might be sharing some or all of the system resources. Such a view is particularly important when system resources such as CPU are not strictly partitioned using resource management facilities.
Thus, processes in the global zone can observe processes and other objects in non-global zones. This allows such processes to have system-wide observability. The ability to control or send signals to processes in other zones is restricted by the privilege PRIV_PROC_ZONE. The privilege is similar to PRIV_PROC_OWNER because the privilege allows processes to override the restrictions placed on unprivileged processes. In this case, the restriction is that unprivileged processes in the global zone cannot signal or control processes in other zones. This is true even when the user IDs of the processes match or the acting process has the PRIV_PROC_OWNER privilege. The PRIV_PROC_ZONE privilege can be removed from otherwise privileged processes to restrict actions to the global zone.
For information about matching processes by using a zoneidlist, see the pgrep(1) and pkill(1) man pages.
Only processes in the same zone will be visible through system call interfaces that take process IDs, such as the kill and priocntl commands. For information, see the kill(1) and the priocntl(1) man pages.
The ps command has the following modifications:
The -o option is used to specify output format. This option allows you to print the zone ID of a process or the name of the zone in which the process is running.
The -z zonelist option is used to list only processes in the specified zones. Zones can be specified either by zone name or by zone ID. This option is only useful when the command is executed in the global zone.
The -Z option is used to print the name of the zone associated with the process. The name is printed under the column heading ZONE.
For more information, see the ps(1) man page.
A -z zonename option has been added to the following Solaris utilities. You can use this option to filter the information to include only the zone or zones specified.
ipcs (see the ipcs(1) man page)
pgrep (see the pgrep(1) man page)
ptree (see the proc(1) man page)
prstat (see the prstat(1M) man page)
See Table 27–5 for the full list of changes made to commands.
The node name in /etc/nodename returned by uname -n can be set by the zone administrator. The node name must be unique.
This section provides information about file system issues on a Solaris system with zones installed. Each zone has its own section of the file system hierarchy, rooted at a directory known as the zone root. Processes in the zone can access only files in the part of the hierarchy that is located under the zone root. The chroot utility can be used in a zone, but only to restrict the process to a root path within the zone. For more information about chroot, see chroot(1M).
The -o nosuid option to the mount utility has the following functionality:
Processes from a setuid binary located on a file system that is mounted using the nosetuid option do not run with the privileges of the setuid binary. The processes run with the privileges of the user that executes the binary.
For example, if a user executes a setuid binary that is owned by root, the processes run with the privileges of the user.
Opening device-special entries in the file system is not allowed. This behavior is equivalent to specifying the nodevices option.
This file system-specific option is available to all Solaris file systems that can be mounted with mount utilities, as described in the mount(1M) man page. In this guide, these file systems are listed in Mounting File Systems in Zones. Mounting capabilities are also described. For more information about the -o nosuid option, see “Accessing Network File Systems (Reference)” in System Administration Guide: Network Services.
When file systems are mounted from within a zone, the nodevices option applies. For example, if a zone is granted access to a block device (/dev/dsk/c0t0d0s7) and a raw device (/dev/rdsk/c0t0d0s7) corresponding to a UFS file system, the file system is automatically mounted nodevices when mounted from within a zone. This rule does not apply to mounts specified through a zonecfg configuration.
Options for mounting file systems in non-global zones are described in the following table. Procedures for these mounting alternatives are provided in Configuring, Verifying, and Committing a Zone and Mounting File Systems in Running Non-Global Zones.
Any file system type not listed in the table can be specified in the configuration if it has a mount binary in /usr/lib/fstype/mount.
File System |
Mounting Options in a Non-Global Zone |
---|---|
AutoFS |
Cannot be mounted using zonecfg, cannot be manually mounted from the global zone into a non-global zone. Can be mounted from within the zone. |
CacheFS |
Cannot be used in a non-global zone. |
FDFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
HSFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
LOFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
MNTFS |
Cannot be mounted using zonecfg, cannot be manually mounted from the global zone into a non-global zone. Can be mounted from within the zone. |
NFS |
Cannot be mounted using zonecfg. V2, V3, and V4, which are the versions currently supported in zones, can be mounted from within the zone. |
PCFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
PROCFS |
Cannot be mounted using zonecfg, cannot be manually mounted from the global zone into a non-global zone. Can be mounted from within the zone. |
TMPFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
UDFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
UFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. |
XMEMFS |
Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone. Support for this file system is being removed from the Solaris system in a future release. |
ZFS |
Can be mounted using the zonecfg dataset and fs resource types. |
For more information, see How to Configure the Zone, Mounting File Systems in Running Non-Global Zones, and the mount(1M) man page.
The ability to unmount a file system will depend on who performed the initial mount. If a file system is specified as part of the zone's configuration using the zonecfg command, the global zone owns this mount and the zone administrator for the non-global cannot unmount the file system. If the file system is mounted from within the non-global zone, for example, by specifying the mount in the zone's /etc/vfstab file, the zone administrator in the non-global zone can unmount the file system.
There are security restrictions on mounting certain file systems from within a zone. Other file systems exhibit special behavior when mounted in a zone. The list of modified file systems follows.
Autofs is a client-side service that automatically mounts the appropriate file system. When a client attempts to access a file system that is not presently mounted, the AutoFS file system intercepts the request and calls automountd to mount the requested directory. AutoFS mounts established within a zone are local to that zone. The mounts cannot be accessed from other zones, including the global zone. The mounts are removed when the zone is halted or rebooted. For more information on AutoFS, see How Autofs Works in System Administration Guide: Network Services.
Each zone runs its own copy of automountd. The auto maps and timeouts are controlled by the zone administrator. You cannot trigger a mount in another zone by crossing an AutoFS mount point for a non-global zone from the global zone.
Certain AutoFS mounts are created in the kernel when another mount is triggered. Such mounts cannot be removed by using the regular umount interface because they must be mounted or unmounted as a group. Note that this functionality is provided for zone shutdown.
MNTFS is a virtual file system that provides read-only access to the table of mounted file systems for the local system. The set of file systems visible by using mnttab from within a non-global zone is the set of file systems mounted in the zone, plus an entry for root (/) . Mount points with a special device that is not accessible from within the zone, such as /dev/rdsk/c0t0d0s0, have their special device set to the same as the mount point. All mounts in the system are visible from the global zone's /etc/mnttab table. For more information on MNTFS, see Chapter 18, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems.
NFS mounts established within a zone are local to that zone. The mounts cannot be accessed from other zones, including the global zone. The mounts are removed when the zone is halted or rebooted.
As documented in the mount_nfs(1M) man page, an NFS server should not attempt to mount its own file systems. Thus, a zone should not NFS mount a file system exported by the global zone. Zones cannot be NFS servers. From within a zone, NFS mounts behave as though mounted with the nodevices option.
The nfsstat command output only pertains to the zone in which the command is run. For example, if the command is run in the global zone, only information about the global zone is reported. For more information about the nfsstat command, see nfsstat(1M).
The zlogin command will fail if any of its open files or any portion of its address space reside on NFS. For more information, see zlogin Command.
The /proc file system, or PROCFS, provides process visibility and access restrictions as well as information about the zone association of processes. Only processes in the same zone are visible through /proc.
Processes in the global zone can observe processes and other objects in non-global zones. This allows such processes to have system-wide observability.
From within a zone, procfs mounts behave as though mounted with the nodevices option. For more information about procfs, see the proc(4) man page.
The scope of what can be mounted through LOFS is limited to the portion of the file system that is visible to the zone. Hence, there are no restrictions on LOFS mounts in a zone.
When using the zonecfg command to configure storage-based file systems that have an fsck binary, such as UFS, the zone administrator must specify a raw parameter. The parameter indicates the raw (character) device, such as /dev/rdsk/c0t0d0s7. zoneadmd automatically runs the fsck command in non-interactive check-only mode (fsck -m) on this device before it mounts the file system. If the fsck fails, zoneadmd cannot bring the zone to the ready state. The path specified by raw cannot be a relative path.
It is an error to specify a device to fsck for a file system that does not provide an fsck binary in /usr/lib/fstype/fsck. It is also an error if you do not specify a device to fsck if an fsck binary exists for that file system.
For more information, see The zoneadmd Daemon and the fsck(1M)
You can add a ZFS dataset to a non-global zone by using the zonecfg command with the add dataset resource. The dataset will be visible and mounted in the non-global zone and no longer visible in the global zone. The zone administrator can create and destroy file systems within that dataset, create and destroy clones, and modify the properties of the dataset.
The zoned attribute of zfs indicates whether a dataset has been added to a non-global zone.
# zfs get zoned tank/sales NAME PROPERTY VALUE SOURCE tank/sales zoned on local |
If you want to share a dataset from the global zone, you can add an LOFS-mounted ZFS file system by using the zonecfg command with the add fs subcommand. The global administrator is responsible for setting and controlling the properties of the dataset.
For more information on ZFS, see Chapter 10, Oracle Solaris ZFS Advanced Topics, in Oracle Solaris ZFS Administration Guide.
Zones can be NFS clients. Version 2, version 3, and version 4 protocols are supported. For information on these NFS versions, see Features of the NFS Service in System Administration Guide: Network Services.
The default version is NFS version 4. You can enable other NFS versions on a client by using one of the following methods:
You can edit /etc/default/nfs to set NFS_CLIENT_VERSMAX=number so that the zone uses the specified version by default. See Setting Up NFS Services in System Administration Guide: Network Services. Use the procedure How to Select Different Versions of NFS on a Client by Modifying the /etc/default/nfs File from the task map.
You can manually create a version mount. This method overrides the contents of /etc/default/nfs. See Setting Up NFS Services in System Administration Guide: Network Services. Use the procedure How to Use the Command Line to Select Different Versions of NFS on a Client from the task map.
Note that you cannot use the mknod command documented in the mknod(1M) man page to make a special file in a non-global zone.
A zone's file system namespace is a subset of the namespace accessible from the global zone. Unprivileged processes in the global zone are prevented from traversing a non-global zone's file system hierarchy through the following means:
Specifying that the zone root's parent directory is owned, readable, writable, and executable by root only
Restricting access to directories exported by /proc
Note that attempting to access AutoFS nodes mounted for another zone will fail. The global administrator must not have auto maps that descend into other zones.
After a non-global zone is installed, the zone must never be accessed directly from the global zone by any commands other than system backup utilities. Moreover, a non-global zone can no longer be considered secure after it has been exposed to an unknown environment. An example would be a zone placed on a publicly accessible network, where it would be possible for the zone to be compromised and the contents of its file systems altered. If there is any possibility that compromise has occurred, the global administrator should treat the zone as untrusted.
Any command that accepts an alternative root by using the -R or -b options (or the equivalent) must not be used when the following are true:
The command is run in the global zone.
The alternative root refers to any root path within a non-global zone, whether the path is relative to the current running system's global zone or the global zone in an alternative root.
An example is the -R root_path option to the pkgadd utility run from the global zone with a non-global zone root path.
The list of commands, programs, and utilities that use -R with an alternative root path include the following:
auditreduce
bart
flar
flarcreate
installf
localeadm
makeuuid
metaroot
patchadd
patchrm
pkgadd
pkgadm
pkgask
pkgchk
pkgrm
prodreg
removef
routeadm
showrev
syseventadm
The list of commands and programs that use -b with an alternative root path include the following:
add_drv
pprosetup
rem_drv
roleadd
sysidconfig
update_drv
useradd
On a Solaris system with zones installed, the zones can communicate with each other over the network. The zones all have separate bindings, or connections, and the zones can all run their own server daemons. These daemons can listen on the same port numbers without any conflict. The IP stack resolves conflicts by considering the IP addresses for incoming connections. The IP addresses identify the zone.
The IP stack in a system supporting zones implements the separation of network traffic between zones. Applications that receive IP traffic can only receive traffic sent to the same zone.
Each logical interface on the system belongs to a specific zone, the global zone by default. Logical network interfaces assigned to zones though the zonecfg utility are used to communicate over the network. Each stream and connection belongs to the zone of the process that opened it.
Bindings between upper-layer streams and logical interfaces are restricted. A stream can only establish bindings to logical interfaces in the same zone. Likewise, packets from a logical interface can only be passed to upper-layer streams in the same zone as the logical interface.
Each zone has its own set of binds. Each zone can be running the same application listening on the same port number without binds failing because the address is already in use. Each zone can run its own version of the following services:
Internet services daemon with a full configuration file (see the inetd(1M) man page)
sendmail (see the sendmail(1M) man page)
apache (see the apache(1M) man page)
Zones other than the global zone have restricted access to the network. The standard TCP and UDP socket interfaces are available, but SOCK_RAW socket interfaces are restricted to Internet Control Message Protocol (ICMP). ICMP is necessary for detecting and reporting network error conditions or using the ping command.
Each non-global zone that requires network connectivity has one or more dedicated IP addresses. These addresses are associated with logical network interfaces that can be placed in a zone by using the ifconfig command. Zone network interfaces configured by zonecfg will automatically be set up and placed in the zone when it is booted. The ifconfig command can be used to add or remove logical interfaces when the zone is running. Only the global administrator can modify the interface configuration and the network routes.
Within a non-global zone, only that zone's interfaces will be visible to ifconfig.
For more information, see the ifconfig(1M) and if_tcp(7P) man pages.
Between two zones on the same machine, packet delivery is only allowed if there is a “matching route” for the destination and the zone in the forwarding table.
The matching information is implemented as follows:
The source address for the packets is selected on the output interface specified by the matching route.
By default, traffic is permitted between two zones that have addresses on the same subnet. The matching route in this case is the interface route for the subnet.
If there is a default route for a given zone, where the gateway is on one of the zone's subnets, traffic from that zone to all other zones is allowed. The matching route in this case is the default route.
If there is a matching route with the RTF_REJECT flag, packets trigger an ICMP unreachable message. If there is a matching route with the RTF_BLACKHOLE flag, packets are discarded. The global administrator can use the route command options described in the following table to create routes with these flags.
Modifier |
Flag |
Description |
---|---|---|
-reject |
RTF_REJECT |
Emit an ICMP unreachable message when matched. |
-blackhole |
RTF_BLACKHOLE |
Silently discard packets during updates. |
For more information, see the route(1M)
Solaris IP Filter provides stateful packet filtering and network address translation (NAT). A stateful packet filter can monitor the state of active connections and use the information obtained to determine which network packets to allow through the firewall. Solaris IP Filter also includes stateless packet filtering and the ability to create and manage address pools. See Chapter 25, Oracle Solaris IP Filter (Overview), in System Administration Guide: IP Services for additional information.
Solaris IP Filter can be enabled in non-global zones by turning on loopback filtering as described in Chapter 26, Oracle Solaris IP Filter (Tasks), in System Administration Guide: IP Services.
Solaris IP Filter is derived from open source IP Filter software.
IP network multipathing (IPMP) provides physical interface failure detection and transparent network access failover for a system with multiple interfaces on the same IP link. IPMP also provides load spreading of packets for systems with multiple interfaces.
All network configuration is done in the global zone. You can configure IPMP in the global zone, then extend the functionality to non-global zones. The functionality is extended by placing the zone's address in an IPMP group when you configure the zone. Then, if one of the interfaces in the global zone fails, the non-global zone addresses will migrate to another network interface card. A shared-IP zone can have multiple IP addresses, it can be part of multiple IPMP groups, and a given IPMP group can be used by multiple shared-IP zones.
In a given non-global zone, only the interfaces associated with the zone are visible through the ifconfig command.
See How to Extend IP Network Multipathing Functionality to Shared-IP Non-Global Zones. The zones configuration procedure is covered in How to Configure the Zone. For information on IPMP features, components, and usage, see Chapter 30, Introducing IPMP (Overview), in System Administration Guide: IP Services.
An exclusive-IP zone has its own IP-related state and tuning variables. The zone is assigned its own set of data-links when the zone is configured.
For information on features that can be used in an exclusive-IP non-global zone, see Solaris 10 8/07: Exclusive-IP Non-Global Zones. For information on tuning IP ndd variables, see Oracle Solaris Tunable Parameters Reference Manual.
Exclusive-IP zones have separate TCP/IP stacks, so the separation reaches down to the data-link layer. One or more data-link names, which can be a NIC or a VLAN on a NIC, are assigned to an exclusive-IP zone by the global administrator. The zone administrator can configure IP on those data-links with the same flexibility and options as in the global zone.
A data-link name must be assigned exclusively to a single zone.
The dladm show-link command can be used to display data-links assigned to running zones.
For more information, see dladm(1M)
There is no internal loopback of IP packets between exclusive-IP zones. All packets are sent down to the data-link. Typically, this means that the packets are sent out on a network interface. Then, devices like Ethernet switches or IP routers can forward the packets toward their destination, which might be a different zone on the same machine as the sender.
You have the same IP Filter functionality that you have in the global zone in an exclusive-IP zone. IP Filter is also configured the same way in exclusive-IP zones and the global zone.
IP network multipathing (IPMP) provides physical interface failure detection and transparent network access failover for a system with multiple interfaces on the same IP link. In addition to fault tolerance, IPMP also provides load spreading of packets for systems with multiple interfaces.
The data-link configuration is done in the global zone. First, multiple data-link interfaces are assigned to a zone using zonecfg. The multiple data-link interfaces must be attached to the same IP subnet. IPMP can then be configured from within the exclusive-IP zone by the zone administrator. Multiple IPMP groups can be assigned to a given exclusive-IP zone, but those IPMP groups cannot be shared with other zones.
The set of devices available within a zone is restricted to prevent a process in one zone from interfering with processes running in other zones. For example, a process in a zone cannot modify kernel memory or modify the contents of the root disk. Thus, by default, only certain pseudo-devices that are considered safe for use in a zone are available. Additional devices can be made available within specific zones be using the zonecfg utility.
The devfs file system described in the devfs(7FS) man page is used by the Solaris system to manage /devices. Each element in this namespace represents the physical path to a hardware device, pseudo-device, or nexus device. The namespace is a reflection of the device tree. As such, the file system is populated by a hierarchy of directories and device special files.
The /dev file hierarchy, which is today part of the / (root) file system, consists of symbolic links, or logical paths, to the physical paths present in /devices. Applications reference the logical path to a device presented in /dev. The /dev file system is loopback-mounted into the zone using a read-only mount.
The /dev file hierarchy is managed by a system comprised of the components in the following list:
devfsadm (see the devfsadm(1M) man page)
syseventd (see the syseventd(1M) man page)
libdevinfo device information library (see the libdevinfo(3LIB) man page)
devinfo driver (see the devinfo(7D) man page)
Reconfiguration Coordination Manager (RCM) (see Reconfiguration Coordination Manager (RCM) Script Overview in System Administration Guide: Devices and File Systems)
Subsystems that rely on /devices path names are not able to run in non-global zones until /dev path names are established.
You might have devices that you want to assign to specific zones. Allowing unprivileged users to access block devices could permit those devices to be used to cause system panic, bus resets, or other adverse effects. Before making such assignments, consider the following issues:
Before assigning a SCSI tape device to a specific zone, consult the sgen(7D) man page.
Placing a physical device into more than one zone can create a covert channel between zones. Global zone applications that use such a device risk the possibility of compromised data or data corruption by a non-global zone.
In a non-global zone, you can use the modinfo command described in the modinfo(1M) man page to examine the list of loaded kernel modules.
Most operations concerning kernel, device, and platform management will not work inside a non-global zone because modifying platform hardware configurations violates the zone security model. These operations include the following:
Adding and removing drivers
Explicitly loading and unloading kernel modules
Initiating dynamic reconfiguration (DR) operations
Using facilities that affect the state of the physical platform
The following utilities do not work in a zone because they rely on devices that are not normally available:
cdrecord (See the man page in the /usr/share/man/man1 directory. )
cdrw (see the cdrw(1) man page)
rmformat (see the rmformat(1) man page)
add_drv (see the add_drv(1M) man page)
disks (see the disks(1M) man page)
prtconf (see the prtconf(1M) man page)
prtdiag (see the prtdiag(1M) man page)
rem_drv (see the rem_drv(1M) man page)
The eeprom utility can be used in a zone to view settings. The utility cannot be used to change settings. For more information, see the eeprom(1M) and openprom(7D) man pages.
In general, all applications can run in a non-global zone. However, the following types of applications might not be suitable for this environment:
Applications that use privileged operations that affect the system as a whole. Examples include operations that set the global system clock or lock down physical memory.
The few applications dependent upon certain devices that do not exist in a non-global zone, such as /dev/kmem.
Applications that expect to be able to write into /usr, either at runtime or when being installed, patched, or upgraded. This is because /usr is read-only for a non-global zone by default. Sometimes the issues associated with this type of application can be mitigated without changing the application itself.
In a shared-IP zone, applications dependent upon devices in /dev/ip.
For additional information about using a resource management feature in a zone, also refer to the chapter that describes the feature in Part 1 of this guide.
Any of the resource controls and attributes described in the resource management chapters can be set in the global and non-global zone /etc/project file, NIS map, or LDAP directory service. The settings for a given zone affect only that zone. A project running autonomously in different zones can have controls set individually in each zone. For example, Project A in the global zone can be set project.cpu-shares=10 while Project A in a non-global zone can be set project.cpu-shares=5. You could have several instances of rcapd running on the system, with each instance operating only on its zone.
The resource controls and attributes used in a zone to control projects, tasks, and processes within that zone are subject to the additional requirements regarding pools and the zone-wide resource controls.
A “one zone, one pool” rule applies to non-global zones. Multiple non-global zones can share the resources of one pool. Processes in the global zone, however, can be bound by a sufficiently privileged process to any pool. The resource controller poold only runs in the global zone, where there is more than one pool for it to operate on. The poolstat utility run in a non-global zone displays only information about the pool associated with the zone. The pooladm command run without arguments in a non-global zone displays only information about the pool associated with the zone.
Zone-wide resource controls do not take effect when they are set in the project file. A zone-wide resource control is set through the zonecfg utility.
This section describes how to use the fair share scheduler (FSS) with zones.
FSS CPU shares for a zone are hierarchical. The shares for the global and non-global zones are set by the global administrator through the zone-wide resource control zone.cpu-shares. The project.cpu-shares resource control can then be defined for each project within that zone to further subdivide the shares set through the zone-wide control.
To assign zone shares by using the zonecfg command, see How to Set zone.cpu-shares in the Global Zone. For more information on project.cpu-shares, see Available Resource Controls. Also see Using the Fair Share Scheduler on a Solaris System With Zones Installed for example procedures that show how to set shares on a temporary basis.
You can use zone.cpu-shares to assign FSS shares for the global zone and for non-global zones. If FSS is the default scheduler on your system and shares are not assigned, each zone, including the global zone, is given one share by default. If you have one non-global zone on your system and you give this zone two shares through zone.cpu-shares, that defines the proportion of CPU which the non-global zone will receive in relation to the global zone. The ratio of CPU between the two zones is 2:1.
The extended accounting subsystem collects and reports information for the entire system (including non-global zones) when run in the global zone. The global administrator can also determine resource consumption on a per-zone basis.
The extended accounting subsystem permits different accounting settings and files on a per-zone basis for process-based and task-based accounting. The exacct records can be tagged with the zone name EXD PROC ZONENAME for processes, and the zone name EXD TASK ZONENAME for tasks. Accounting records are written to the global zone's accounting files as well as the per-zone accounting files. The EXD TASK HOSTNAME, EXD PROC HOSTNAME, and EXD HOSTNAME records contain the uname -n value for the zone in which the process or task executed instead of the global zone's node name.
For information about IPQoS flow accounting, see Chapter 36, Using Flow Accounting and Statistics Gathering (Tasks), in System Administration Guide: IP Services.
Processes are restricted to a subset of privileges. Privilege restriction prevents a zone from performing operations that might affect other zones. The set of privileges limits the capabilities of privileged users within the zone. To display the list of privileges available within a zone, use the ppriv utility.
The following table lists all of the Solaris privileges and the status of each privilege with respect to zones. Optional privileges are not part of the default set of privileges but can be specified through the limitpriv property. Required privileges must be included in the resulting privilege set. Prohibited privileges cannot be included in the resulting privilege set.
The limitpriv property is available beginning with the Solaris 10 11/06 release.
Table 27–1 Status of Privileges in Zones
Privilege |
Status |
Notes |
---|---|---|
cpc_cpu |
Optional |
Access to certain cpc(3CPC) counters |
dtrace_proc |
Optional |
fasttrap and pid providers; plockstat(1M) |
dtrace_user |
Optional |
profile and syscall providers |
graphics_access |
Optional |
ioctl(2) access to agpgart_io(7I) |
graphics_map |
Optional |
mmap(2) access to agpgart_io(7I) |
net_rawaccess |
Optional in shared-IP zones. Default in exclusive-IP zones. |
Raw PF_INET/PF_INET6 packet access |
proc_clock_highres |
Optional |
Use of high resolution timers |
proc_priocntl |
Optional |
Scheduling control; priocntl(1) |
sys_ipc_config |
Optional |
Raising IPC message queue buffer size |
sys_time |
Optional |
System time manipulation; xntp(1M) |
dtrace_kernel |
Prohibited |
Currently unsupported |
proc_zone |
Prohibited |
Currently unsupported |
sys_config |
Prohibited |
Currently unsupported |
sys_devices |
Prohibited |
Currently unsupported |
sys_linkdir |
Prohibited |
Currently unsupported |
sys_net_config |
Prohibited |
Currently unsupported |
sys_res_config |
Prohibited |
Currently unsupported |
sys_suser_compat |
Prohibited |
Currently unsupported |
proc_exec |
Required, Default |
Used to start init(1M) |
proc_fork |
Required, Default |
Used to start init(1M) |
sys_mount |
Required, Default |
Needed to mount required file systems |
sys_ip_config |
Required, Default in exclusive-IP zones Prohibited in shared-IP zones |
Required to boot zone and initialize IP networking in exclusive-IP zone |
contract_event |
Default |
Used by contract file system |
contract_observer |
Default |
Contract observation regardless of UID |
file_chown |
Default |
File ownership changes |
file_chown_self |
Default |
Owner/group changes for own files |
file_dac_execute |
Default |
Execute access regardless of mode/ACL |
file_dac_read |
Default |
Read access regardless of mode/ACL |
file_dac_search |
Default |
Search access regardless of mode/ACL |
file_dac_write |
Default |
Write access regardless of mode/ACL |
file_link_any |
Default |
Link access regardless of owner |
file_owner |
Default |
Other access regardless of owner |
file_setid |
Default |
Permission changes for setid, setgid, setuid files |
ipc_dac_read |
Default |
IPC read access regardless of mode |
ipc_dac_owner |
Default |
IPC write access regardless of mode |
ipc_owner |
Default |
IPC other access regardless of mode |
net_icmpaccess |
Default |
ICMP packet access: ping(1M) |
net_privaddr |
Default |
Binding to privileged ports |
proc_audit |
Default |
Generation of audit records |
proc_chroot |
Default |
Changing of root directory |
proc_info |
Default |
Process examination |
proc_lock_memory |
Default |
Locking memory; shmctl(2)and mlock(3C) If this privilege is assigned to a non-global zone by the system administrator, consider also setting the zone.max-locked-memory resource control to prevent the zone from locking all memory. |
proc_owner |
Default |
Process control regardless of owner |
proc_session |
Default |
Process control regardless of session |
proc_setid |
Default |
Setting of user/group IDs at will |
proc_taskid |
Default |
Assigning of task IDs to caller |
sys_acct |
Default |
Management of accounting |
sys_admin |
Default |
Simple system administration tasks |
sys_audit |
Default |
Management of auditing |
sys_nfs |
Default |
NFS client support |
sys_resource |
Default |
Resource limit manipulation |
The following table lists all of the Solaris Trusted Extensions privileges and the status of each privilege with respect to zones. Optional privileges are not part of the default set of privileges but can be specified through the limitpriv property.
These privileges are interpreted only if the system is configured with Solaris Trusted Extensions.
Solaris Trusted Extensions Privilege |
Status |
Notes |
---|---|---|
file_downgrade_sl |
Optional |
Set the sensitivity label of file or directory to a sensitivity label that does not dominate the existing sensitivity label |
file_upgrade_sl |
Optional |
Set the sensitivity label of file or directory to a sensitivity label that dominates the existing sensitivity label |
sys_trans_label |
Optional |
Translate labels not dominated by sensitivity label |
win_colormap |
Optional |
Colormap restrictions override |
win_config |
Optional |
Configure or destroy resources that are permanently retained by the X server |
win_dac_read |
Optional |
Read from window resource not owned by client's user ID |
win_dac_write |
Optional |
Write to or create window resource not owned by client's user ID |
win_devices |
Optional |
Perform operations on input devices. |
win_dga |
Optional |
Use direct graphics access X protocol extensions; frame buffer privileges needed |
win_downgrade_sl |
Optional |
Change sensitivity label of window resource to new label dominated by existing label |
win_fontpath |
Optional |
Add an additional font path |
win_mac_read |
Optional |
Read from window resource with a label that dominates the client's label |
win_mac_write |
Optional |
Write to window resource with a label not equal to the client's label |
win_selection |
Optional |
Request data moves without confirmer intervention |
win_upgrade_sl |
Optional |
Change sensitivity label of window resource to a new label not dominated by existing label |
net_bindmlp |
Default |
Allows binding to a multilevel port (MLP) |
net_mac_aware |
Default |
Allows reading down via NFS |
To alter privileges in a non-global zone configuration, see Configuring, Verifying, and Committing a Zone.
To inspect privilege sets, see Using the ppriv Utility. For more information about privileges, see the ppriv(1) man page and System Administration Guide: Security Services.
The Internet Protocol Security Architecture (IPsec), which provides IP datagram protection, is described in Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services. The Internet Key Exchange (IKE) protocol is used to manage the required keying material for authentication and encryption automatically.
For more information, see the ipsecconf(1M) and ipseckey(1M) man pages.
IPsec can be used in the global zone. However, IPsec in a non-global zone cannot use IKE. Therefore, you must manage the IPsec keys and policy for the non-global zones by using the Internet Key Exchange (IKE) protocol in the the global zone. Use the source address that corresponds to the non-global zone that you are configuring.
IPsec can be used in exclusive-IP zones.
Solaris auditing is described in Chapter 28, Oracle Solaris Auditing (Overview), in System Administration Guide: Security Services. For zones considerations associated with auditing, see the following sections:
Chapter 29, Planning for Oracle Solaris Auditing, in System Administration Guide: Security Services
Auditing and Solaris Zones in System Administration Guide: Security Services
An audit record describes an event, such as logging in to a system or writing to a file. The record is composed of tokens, which are sets of audit data. By using the zonename token, you can configure Solaris auditing to identify audit events by zone. Use of the zonename token allows you to produce the following information:
Audit records that are marked with the name of the zone that generated the record
An audit log for a specific zone that the global administrator can make available to the zone administrator
Solaris audit trails are configured in the global zone. Audit policy is set in the global zone and applies to processes in all zones. The audit records can be marked with the name of the zone in which the event occurred. To include zone names in audit records, you must edit the /etc/security/audit_startup file before you install any non-global zones. The zone name selection is case-sensitive.
To configure auditing in the global zone to include all zone audit records, add this line to the /etc/security/audit_startup file:
/usr/sbin/auditconfig -setpolicy +zonename |
As the global administrator in the global zone, execute the auditconfig utility:
global# auditconfig -setpolicy +zonename |
For additional information, see the audit_startup(1M) and auditconfig(1M) man pages and “Configuring Audit Files (Task Map)” in System Administration Guide: Security Services.
When a non-global zone is installed, the audit_control file and the audit_user file in the global zone are copied to the zone's /etc/security directory. These files might require modification to reflect the zone's audit needs.
For example, each zone can be configured to audit some users differently from others. To apply different per-user preselection criteria, both the audit_control and the audit_user files must be edited. The audit_user file in the non-global zone might also require revisions to reflect the user base for the zone if necessary. Because each zone can be configured differently with regard to auditing users, it is possible for the audit_user file to be empty.
For additional information, see the audit_control(4) and audit_user(4) man pages.
By including the zonename token as described in Configuring Audit in the Global Zone, Solaris audit records can be categorized by zone. Records from different zones can then be collected by using the auditreduce command to create logs for a specific zone.
For more information, see the audit_startup(1M) and auditreduce(1M) man pages.
The coreadm command is used to specify the name and location of core files produced by abnormally terminating processes. Core file paths that include the zonename of the zone in which the process executed can be produced by specifying the %z variable. The path name is relative to a zone's root directory.
For more information, see the coreadm(1M) and core(4) man pages.
DTrace programs that only require the dtrace_proc and dtrace_user privileges can be run in a non-global zone. To add these privileges to the set of privileges available in the non-global zone, use the zonecfg limitpriv property. For instructions, see How to Use DTrace.
The providers supported through dtrace_proc are fasttrap and pid. The providers supported through dtrace_user are profile and syscall. DTrace providers and actions are limited in scope to the zone.
Also see Privileges in a Non-Global Zone for more information.
You can perform backups in individual non-global zones, or back up the entire system from the global zone.
Because many non-global zones share files with the global zone through the use of loopback file system read-only mounts (usually /usr, /lib, /sbin, and /platform), you must use a global zone backup method to back up lofs directories.
Do not back up the lofs file systems shared with the global zone in non-global zones. An attempt by the non-global administrator to restore lofs file systems from a non-global zone could cause a serious problem.
You might choose to perform your backups from the global zone in the following cases:
You want to back up the configurations of your non-global zones as well as the application data.
Your primary concern is the ability to recover from a disaster. If you need to restore everything or almost everything on your system, including the root file systems of your zones and their configuration data as well as the data in your global zone, backups should take place in the global zone.
You want to use the ufsdump command to perform a data backup. Because importing a physical disk device into a non-global zone would change the security profile of the zone, ufsdump should only be used from the global zone.
You have commercial network backup software.
Your network backup software should be configured to skip all inherited lofs file systems if possible. The backup should be performed when the zone and its applications have quiesced the data to be backed up.
You might decide to perform backups within the non-global zones in the following cases.
The non-global zone administrator needs the ability to recover from less serious failures or to restore application or user data specific to a zone.
You want to use programs that back up on a file-by-file basis, such as tar or cpio. See the tar(1) and cpio(1) man pages.
You use the backup software of a particular application or service running in a zone. It might be difficult to execute the backup software from the global zone because application environments, such as directory path and installed software, would be different between the global zone and the non-global zone.
If the application can perform a snapshot on its own backup schedule in each non-global zone and store those backups in a writable directory exported from the global zone, the global zone administrator can pick up those individual backups as part of the backup strategy from the global zone.
You can back up everything in the non-global zone, or, because a zone's configuration changes less frequently, you can perform backups of the application data only.
If application data is kept in a particular part of the file system, you might decide to perform regular backups of this data only. The zone's root file system might not have to be backed up as often because it changes less frequently.
You will have to determine where the application places its files. Locations where files can be stored include the following:
Users' home directories
/etc for configuration data files
/var
Assuming the application administrator knows where the data is stored, it might be possible to create a system in which a per-zone writable directory is made available to each zone. Each zone can then store its own backups, and the global administrator can make this location one of the places on the system to back up.
If the database application data is not under its own directory, the following rules apply:
Ensure that the databases are in a consistent state first.
Databases must be quiesced because they have internal buffers to flush to disk. Make sure that the databases in non-global zones have come down before starting the backup from the global zone.
Within each zone, use file system features to make a snapshot of the data, then back up the snapshots directly from the global zone.
This process will minimize elapsed time for the backup window and remove the need for backup clients/modules in all of the zones.
Each non-global zone can take a snapshot of its private file systems when it is convenient for that zone and the application has been briefly quiesced. Later, the global zone can back up each of the snapshots and put them on tape after the application is back in service.
This method has the following advantages:
Fewer tape devices are needed.
There is no need for coordination between the non-global zones.
There is no need to assign devices directly to zones, which improves security.
Generally, this method keeps system management in the global zone, which is preferred.
In the case of a restore where the backups were done from the global zone, the global administrator can reinstall the affected zones and then restore that zone's files. Note that this assumes the following:
The zone being restored has the same configuration as it did when the backup was done.
The global zone has not been upgraded or patched between the time when the backup was done and the time when the zone is restored.
Otherwise, the restore could overwrite some files that should be merged by hand.
For example, you might need to merge files by hand if a global zone has been patched after the backup, but prior to the restore of the non-global zone. In this case, you would have to be careful when restoring a zone's files that were backed up since a backed up file might not be compatible with the newly installed zone that was built after the patches were applied to the global zone. In this case, you would have to examine the files individually and compare them to the copies in the newly installed zone. In most cases, you will find that the file can be copied directly in, but in some cases, you must merge the changes originally made to the file into the newly installed or patched copy in the zone.
If all file systems in the global zone are lost, restoring everything in the global zone restores the non-global zones as well, as long as the respective root file systems of the non-global zones were included in the backup.
The commands identified in Table 27–3 provide the primary administrative interface to the zones facility.
Table 27–3 Commands Used to Administer Zones
Command Reference |
Description |
---|---|
Log in to a non-global zone |
|
Prints the name of the current zone |
|
Administers zones on a system |
|
Used to set up a zone configuration |
|
Used to map between zone ID and name |
|
Provides description of zones facility |
|
Zone console device driver |
The zoneadmd daemon is the primary process for managing the zone's virtual platform. The man page for the zoneadmd daemon is zoneadmd(1M). The daemon does not constitute a programming interface.
The commands in the next table are used with the resource capping daemon.
Table 27–4 Commands Used With rcapd
Command Reference |
Description |
---|---|
Monitors the resource utilization of capped projects. |
|
Configures the resource capping daemon, displays the current status of the resource capping daemon if it has been configured, and enables or disables resource capping. Also used to set a temporary memory cap. |
|
The resource capping daemon. |
The commands identified in the following table have been modified for use on a Solaris system with zones installed. These commands have options that are specific to zones or present information differently. The commands are listed by man page section.
Table 27–5 Commands Modified for Use on a Solaris System With Zones Installed
Command Reference |
Description |
---|---|
Added -z zone option. This option is only useful when the command is executed in the global zone. |
|
Added -z zone option. This option is only useful when the command is executed in the global zone. |
|
Added -z zoneidlist option. This option is only useful when the command is executed in the global zone. |
|
Added the expression zone for use with the -l option to list all privileges available in the current zone. Also use the option -v after zone to obtain verbose output. |
|
Zone ID can be used in idlist and -i idtype to specify processes. You can use the priocntl -i zoneid command to move running processes into a different scheduling class in a non-global zone. |
|
Added -z zone option to ptree only. This option is only useful when the command is executed in the global zone. |
|
Added zonename and zoneid to list of recognized format names used with the -o option. Added -z zonelist to list only processes in the specified zones. Zones can be specified either by zone name or by zone ID. This option is only useful when the command is executed in the global zone. Added -Z to print the name of the zone associated with the process. The name is printed under an additional column header, ZONE. |
|
Added zoneid to list of valid arguments used with the -i option. |
|
If executed in a non-global zone in which the pools facility is enabled, the -b, -c -g, -m, -p, -u, -w, and -y options display values only for processors that are in the processor set of the pool to which the zone is bound. |
|
Added zonename token. |
|
Added -z zone-name option. Added ability to get an audit log of a zone. |
|
Added variable %z to identify the zone in which process executed. |
|
Added -Z option to display mounts in all visible zones. |
|
Added zone option for global zone use (the default), and -zone zonename for non-global zone use. |
|
If executed in a non-global zone in which the pools facility is enabled, information is provided only for those processors that are in the processor set of the pool to which the zone is bound. |
|
If executed in the global zone, kstats are displayed for all zones. If executed in a non-global zone, only kstats with a matching zoneid are displayed. |
|
If executed in a non-global zone in which the pools facility is enabled, command only displays lines for the processors that are in the processor set of the pool to which the zone is bound. |
|
When used in the global zone, displays information for all zones. ndd on the TCP/IP modules in an exclusive-IP zone only displays information for that zone. |
|
Displays information for the current zone only. |
|
Displays statistics for the current zone only. |
|
Added zoneid list. Also see Resource Pools Used in Zones for information about using zones with resource pools. |
|
Added -z zoneidlist option. Also added -Z option. If executed in a non-global zone in which the pools facility is enabled, the percentage of recent CPU time used by the process is displayed only for the processors in the processor set of the pool to which the zone is bound. Output of the -a, -t, -T, -J, and -Z options displays a SWAP instead of a SIZE column. The swap reported is the total swap consumed by the zone's processes and tmpfs mounts. This value assists in monitoring the swap reserved by each zone, which can be used to choose a reasonable zone.max-swap setting. |
|
If executed in a non-global zone, only information about the processors visible to the zone is displayed. |
|
Usage change. When specified from within a non-global zone, the -F option has no effect because the “don't fragment” bit is always set. |
|
When executed in a non-global zone in which the pools facility is enabled, statistics are reported only for the processors in the processor set of the pool to which the zone is bound. Applies to output from the -p option and the page, faults, and cpu report fields. |
|
Added AUDIT_ZONENAME to generate a zone ID token with each audit record. |
|
Added P_ZONEID id argument. |
|
If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. |
|
If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. |
|
Added P_ZONEID as idtype. Added zone to possible choices for P_MYID specification. Added P_ZONEID to valid idtype list in EINVAL error description. |
|
If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. |
|
If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. |
|
If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. |
|
Changed PRIV_SYS_CONFIG to PRIV_SYS_ADMIN. |
|
ENOENT is returned if file pointed to by file is not an absolute path. |
|
If the caller is in a non-global zone and the pools facility is enabled, the behavior is equivalent to calling with a psetid of PS_MYID. |
|
Added zone IDs to target processes that can be specified. Added zone ID to EINVAL error description. |
|
Added “zone” string for the set of all privileges available within the caller's zone. |
|
If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. |
|
If the caller is in a non-global zone and the pools facility enabled, sysconf(_SC_NPROCESSORS_CONF) and sysconf(_SC_NPROCESSORS_ONLN) return the number of processors in the processor set of the pool to which the zone is bound. |
|
Added ucred_getzoneid() function, which returns the zone ID of the process or -1 if the zone ID is not available. |
|
Added n_type: NT_ZONENAME. This entry contains a string that describes the name of the zone in which the process was running. |
|
Now provides optional parameters and an environment variable in support of zones. |
|
Added capability to obtain information on processes running in zones. |
|
Added in<zone name> field that is used if the zonename audit policy is set. |
|
Added PRIV_PROC_ZONE, which allows a process to trace or send signals to processes in other zones. See zones(5). |
|
Added zone ioctl() calls. |
|
Added zone parameter. |
|
Added crgetzoneid(), which returns the zone ID from the user credential pointed to by cr. |