System Administration Guide: Virtualization Using the Solaris Operating System

Chapter 26 Solaris Zones Administration (Overview)

This chapter covers these general zone administration topics:

For information on lx branded zones, see Part III, Linux Branded Zones.

Global Zone Visibility and Access

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) pkill(1) man pages.

Process ID Visibility in Zones

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.

System Observability in Zones

The ps command has the following modifications:

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.

See Table 26–5 for the full list of changes made to commands.

Non-Global Zone Node Name

The node name in /etc/nodename returned by uname -n can be set by the zone administrator. The node name must be unique.

File Systems and Non-Global Zones

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

The -o nosuid option to the mount utility has the following functionality:

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.

Mounting File Systems in Zones

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 

Support for this file system has been removed from Solaris with this 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.

Unmounting File Systems in Zones

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, then the global zone owns this mount and the non-global zone administrator 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, then the non-global zone administrator can unmount the file system.

Security Restrictions and File System Behavior

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

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

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 19, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems.

NFS

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.

PROCFS

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.

LOFS

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.

UFS, UDFS, PCFS, and other storage-based file systems

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/fs/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)

ZFS

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, 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, ZFS Advanced Topics, in Solaris ZFS Administration Guide.

Non-Global Zones as NFS Clients

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:

Use of mknod Prohibited in a Zone

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.

Traversing File Systems

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:

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.

Restriction on Accessing A Non-Global Zone From the Global Zone

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:

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:

The list of commands and programs that use -b with an alternative root path include the following:

Networking in Shared-IP Non-Global Zones

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.

Shared-IP Zone Partitioning

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:

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.

Shared-IP Network Interfaces

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.

IP Traffic Between Shared-IP Zones on the Same Machine

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:

Solaris IP Filter in Shared-IP Zones

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, 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, Solaris IP Filter (Tasks), in System Administration Guide: IP Services.

Solaris IP Filter is derived from open source IP Filter software.

IP Network Multipathing in Shared-IP Zones

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.

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 12, Introducing IPMP, in System Administration Guide: Network Interfaces and Network Virtualization.

Networking in Exclusive-IP Non-Global Zones

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 Exclusive-IP Non-Global Zones. For information on tuning IP ndd variables, see Solaris Tunable Parameters Reference Manual.

Exclusive-IP Zone Partitioning

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.

Exclusive-IP Data-Link Interfaces

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)

IP Traffic Between Exclusive-IP Zones on the Same Machine

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.

Solaris IP Filter in Exclusive-IP Zones

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 in Exclusive-IP Zones

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.

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.

Device Use in Non-Global 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 by using the zonecfg utility.

/dev and the /devices Namespace

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.

Devices are grouped according to the relative /dev hierarchy. For example, all of the devices under /dev in the global zone are grouped as global zone devices. For a non-global zone, the devices are grouped in a /dev directory under the zone's root path. Each group is a mounted /dev file system instance that is mounted under the /dev directory. Thus, the global zone devices are mounted under /dev, while the devices for a non-global zone named my-zone are mounted under /my-zone_rootpath/dev.

The /dev file hierarchy is managed by the dev file system described in the dev(7FS) man page.


Caution – Caution –

Subsystems that rely on /devices path names are not able to run in non-global zones. The subsystems must be updated to use /dev path names.


Exclusive-Use Devices

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:

Device Driver Administration

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:

Utilities That Do Not Work or Are Modified in Non-Global Zones

Utilities That Do Not Work in Non-Global Zones

The following utilities do not work in a zone because they rely on devices that are not normally available:

SPARC: Utility Modified for Use in a Non-Global Zone

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.

Running Applications in Non-Global Zones

In general, all applications can run in a non-global zone. However, the following types of applications might not be suitable for this environment:

Resource Controls Used in Non-Global Zones

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.

Fair Share Scheduler on a Solaris System With Zones Installed

This section describes how to use the fair share scheduler (FSS) with zones.

FSS Share Division in a Global or Non-Global Zone

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.

Share Balance Between Zones

You can use zone.cpu-shares to assign FSS shares in the global zone and in non-global zones. If FSS is the default scheduler on your system and shares are not assigned, each 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.

Extended Accounting on a Solaris System With Zones Installed

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 31, Using Flow Accounting and Statistics Gathering (Tasks), in System Administration Guide: IP Services.

Privileges in a Non-Global Zone

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 from within a given 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.

Table 26–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.


Note –

Trusted Solaris privileges are interpreted only if the system is configured with Trusted Extensions.


Table 26–2 Status of Solaris Trusted Extensions Privileges in Zones

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 through 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.

Using IP Security Architecture in Zones

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.

IP Security Architecture in Shared-IP Zones

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 global zone. Use the source address that corresponds to the non-global zone that you are configuring.

IP Security Architecture in Exclusive-IP Zones

IPsec can be used in exclusive-IP zones.

Using Solaris Auditing in Zones

Solaris auditing is described in Chapter 28, Solaris Auditing (Overview), in System Administration Guide: Security Services. For zones considerations associated with auditing, see the following sections:

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:

Configuring Audit in the Global Zone

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.

Configuring User Audit Characteristics in a Non-Global Zone

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.

Providing Audit Records for a Specific Non-Global Zone

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.

Core Files in Zones

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.

Running DTrace in a Non-Global Zone

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.

About Backing Up a Solaris System With Zones Installed

You can perform backups in individual non-global zones, or back up the entire system from the global zone.

Backing Up Loopback File System Directories

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.


Caution – Caution –

Do not back up the lofs file systems 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.


Backing Up Your System From the Global Zone

You might choose to perform your backups from the global zone in the following cases:

Backing Up Individual Non-Global Zones on Your System

You might decide to perform backups within the non-global zones in the following cases.

Determining What to Back Up in Non-Global Zones

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.

Backing Up 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:

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.

General Database Backup Operations

If the database application data is not under its own directory, the following rules apply:

Tape Backups

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:

About Restoring Non-Global Zones

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:

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.


Note –

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.


Commands Used on a Solaris System With Zones Installed

The commands identified in Table 26–3 provide the primary administrative interface to the zones facility.

Table 26–3 Commands Used to Administer Zones

Command Reference 

Description 

zlogin(1)

Log in to a non-global zone 

zonename(1)

Prints the name of the current zone 

zoneadm(1M)

Administers zones on a system 

zonecfg(1M)

Used to set up a zone configuration 

getzoneid(3C)

Used to map between zone ID and name 

zones(5)

Provides description of zones facility 

zcons(7D)

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 26–4 Commands Used With rcapd

Command Reference 

Description 

rcapstat(1)

Monitors the resource utilization of capped projects. 

rcapadm(1M)

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 

rcapd(1M)

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 26–5 Commands Modified for Use on a Solaris System With Zones Installed

Command Reference 

Description 

ipcrm(1)

Added -z zone option. This option is only useful when the command is executed in the global zone.

ipcs(1)

Added -z zone option. This option is only useful when the command is executed in the global zone.

pgrep(1)

Added -z zoneidlist option. This option is only useful when the command is executed in the global zone.

ppriv(1)

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.

priocntl(1)

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.

proc(1)

Added -z zone option to ptree only. This option is only useful when the command is executed in the global zone.

ps(1)

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.

renice(1)

Added zoneid to list of valid arguments used with the -i option.

sar(1)

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.

auditconfig(1M)

Added zonename token.

auditreduce(1M)

Added -z zone-name option. Added ability to get an audit log of a zone.

coreadm(1M)

Added variable %z to identify the zone in which process executed.

df(1M)

Added -Z option to display mounts in all visible zones. This option has no effect in a non-global zone.

ifconfig(1M)

Added zone option for global zone use (the default), and -zone zonename for non-global zone use.

iostat(1M)

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. 

kstat(1M)

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.

mpstat(1M)

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. 

ndd(1M)

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.

netstat(1M)

Displays information for the current zone only. 

nfsstat(1M)

Displays statistics for the current zone only. 

poolbind(1M)

Added zoneid list. Also see Resource Pools Used in Zones for information about using zones with resource pools.

prstat(1M)

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.

psrinfo(1M)

If executed in a non-global zone, only information about the processors visible to the zone is displayed. 

traceroute(1M)

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.

vmstat(1M)

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.

auditon(2)

Added AUDIT_ZONENAME to generate a zone ID token with each audit record.

priocntl(2)

Added P_ZONEID id argument.

processor_info(2)

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. 

p_online(2)

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. 

pset_bind(2)

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.

pset_info(2)

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. 

pset_list(2)

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. 

pset_setattr(2)

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. 

sysinfo(2)

Changed PRIV_SYS_CONFIG to PRIV_SYS_ADMIN.

umount(2)

ENOENT is returned if file pointed to by file is not an absolute path.

getloadavg(3C)

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.

getpriority(3C)

Added zone IDs to target processes that can be specified. Added zone ID to EINVAL error description.

priv_str_to_set(3C)

Added “zone” string for the set of all privileges available within the caller's zone. 

pset_getloadavg(3C)

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. 

sysconf(3C)

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 total and online processors in the processor set of the pool to which the zone is bound.

ucred_get(3C)

Added ucred_getzoneid() function, which returns the zone ID of the process or -1 if the zone ID is not available.

core(4)

Added n_type: NT_ZONENAME. This entry contains a string that describes the name of the zone in which the process was running.

pkginfo(4)

Now provides optional parameters and an environment variable in support of zones. 

proc(4)

Added capability to obtain information on processes running in zones. 

audit_syslog(5)

Added in<zone name> field that is used if the zonename audit policy is set.

privileges(5)

Added PRIV_PROC_ZONE, which allows a process to trace or send signals to processes in other zones. See zones(5).

if_tcp(7P)

Added zone ioctl() calls.

cmn_err(9F)

Added zone parameter. 

ddi_cred(9F)

Added crgetzoneid(), which returns the zone ID from the user credential pointed to by cr.