Qualification Best Practices for Application Support in Non-Global Zones

Print-friendly Version

Solaris Containers technology offers a virtualized runtime environment that has established limits for an application's consumption of system resources, such as CPUs. Solaris Containers has two components: Resource Management and Solaris Zones.

The resource management part of Solaris Containers addresses how much of the system resources will go to each application. For example, it is possible to dedicate certain CPUs to one particular application, or allow different applications to share CPUs while retaining a minimum guaranteed amount of CPUs. The technologies that allow the dedication of CPUs to an application, and the sharing with a minimum guarantee, are called Dynamic Resource Pools and the Fair Share Scheduler, respectively.

Solaris Zones partitioning technology is used to virtualize operating system services and to provide an isolated and secure environment for hosting and running applications. There are two different types of zones: global and non-global.

Solaris Containers delivers a virtualized environment for lowering total cost of ownership (TCO) via server consolidation. The administrator can use both the resource management tools as well as the zones to create environments -- called containers -- that isolate applications and share system resources. It's the sharing of resources that enables the higher utilization rates and helps lower the overall cost.

With a fresh installation of the Solaris 10 Operating System (OS), no additional containers are installed; just the full OS is present, and this called the global zone. The administrator of this global zone is the one who creates any additional containers by installing non-global zones and assigning resource management rules to these zones. Processes in a container are isolated from processes in other containers. This is done by preventing the process from seeing from one non-global zone into the other non-global zone.

Certain constraints are applied to the non-global zone processes to achieve container isolation. Section 4 presents the details of these constraints. Because of these constraints, the process in a non-global zone may not work due to:

• Failure of some privileged system calls
• Unavailability of some device nodes and file systems
• Restricted network control functions

Therefore, it is advisable to perform application qualification in order for the application to support the non-global zone.

This paper presents best practices for qualifying applications for non-global zone. The discussion in the paper will focus on the Solaris Zones part of Solaris Containers because:

• The resource management aspects of Solaris Containers are transparent to the application qualification.
• The Solaris Zones feature does introduce some new restrictions on the applications.

Depending on application type, zone configuration, and engineering resource availability, several qualification processes are proposed so that ISVs can choose the process that best suits their needs. This document provides technical background for the restrictions, qualification process, and step-by-step procedures for qualifying an application for a zone.

This paper refers to the Solaris Ready Test Suite 1.1 (or higher); this Suite is designed to help you confirm that your applications will successfully run on the Solaris 10 OS. The Suite includes Solaris Application Scanner, a fast scanning tool for both application ELF binaries and source. The scanner is primarily intended to check for near-certain failures caused by interfaces or libraries going away in a Solaris release. Also included are DTrace scripts to check for system calls, application crashes due to signals, and system resource usage, as well as listing all the files and ports opened.

A qualification process for non-global zone may involve up to three separate operations:

1. Perform application qualification in a non-global zone. If no errors are found, the application is also qualified for the global zone.
2. Invoke a script in the global zone for monitoring test operations performed in the global zone or in a non-global zone. This operation will help the test engineer to identify the cause of errors that are related to the zone restrictions.
3. Scan application source code for any usage of APIs and device nodes that are non-compliant with non-global zones. If no issues are reported by the tool, the application is likely to work in both global and non-global zones. This operation supplements the confidence level of the test performed in Operation 1.

Operation 1 is recommended for ISVs that want to add support for non-global zones to their applications. An ISV may choose to perform all three operations, any one of them, or a combination of them. Operation 2 and 3 only detect runtime errors. If an ISV decides to only perform Operation 2 or Operation 3, an additional installation test in a non-global zone needs to be performed separately.

An ISV decides which qualification process to use based on the following factors:

• Application type: privileged versus non-privileged and device usage
• Zone configuration: file systems, device nodes, network, and system resources that need to be exported to a zone
• Test environment: multi-tier and multi-layer software stack
• Test suites: privileged versus non-privileged
• Engineering resources

A brief discussion of each operation and its pros and cons is given below. This discussion assumes a typical application testing process does the following:

• Is performed by a dedicated testing team
• Follows a test plan that defines:
• Testing environment
• Tools used in the testing
• Installation procedures
• Functional tests
• Performance tests
• Acceptance criteria
• Includes a bug reporting mechanism for the development team to resolve issues found by the testing team

Operation 1: Perform application qualification in a non-global zone.

Since a non-global zone has more constraints than the global zone has, a successful test in a non-global zone will automatically qualify the application for the global zone. This operation requires an ISV to decide on a zone configuration or a set of zone configurations first and to perform application installation, functional, and performance tests in the non-global zone. A sample zone configuration setup is shown in Section 3.1.

The test plan has to be updated to reflect additional procedures for zone configuration and setup. This operation also requires the ISV to install and to bring up all test suites and tools and other layers of software stack that are required by the functional and performance tests, in the non-global zone. A modification to the testing tools might be required if the tools cannot run in the non-global zone.

This operation gives the most complete testing and highest confidence level among all operations. However, it requires more engineering resources than other operations.

Operation 2: Perform application qualification in the global zone or a non-global zone along with a monitoring script.

The Suite mentioned above provides a utility for monitoring an application's use of device nodes and privileges that are not available in a non-global zone. The suite is launched in the global zone before starting the qualification testing. The qualification tests can be performed in either the global zone or a non-global zone. If no warning is flagged by the suite, the application is very likely to run successfully in a non-global zone.

This operation is used if:

• You cannot bring test tools and other required software stacks to the non-global zone for testing, or
• You need to trace issues that only occur in the non-global zone.

Operation 2 can be performed along with Operation 1. In this case, the monitoring script monitors the process running in a non-global zone and would be useful to identify the cause of errors found in Operation 1. The change to the existing testing procedures is minimal.

The installation qualification will be performed through separate testing. The functional and performance tests are performed in the global zone.

Operation 3: Scan application source code for any use of APIs that are non-compliant with non-global zones.

The suite includes a utility for scanning the source code of the ISV application for the use of non-supported APIs and device nodes in a non-global zone. In addition, the suite will also scan the ELF binaries of third-party libraries for the use of zone-non-compliant APIs in third-party binaries. The output of the suite helps the development team to identify potential issues of an application regarding the support of non-global zones. This operation performs a static scanning of application source and binaries and, therefore, does not require the test engineer to run the application.

This tool will also scan the third-party libraries for the use of zone-non-compliant APIs in third-party binaries. This tool is intended for the development team to identify potential issues of an application to support non-global zones. The tool may report some false positive issues for functions like open(2), ioctl(2), socket(2), link(2), and unlink(2). False positives may be due to:

• The difficulty of getting variable arguments passed to a function
• The design goal of the tool, which is to report any potential issues that may cause an application to fail

This operation may result in no impact or minimal impact on existing testing procedures. With this operation, the development team carries most of the burden of qualifying the application in a non-global zone. This may not be a bad thing as the development team needs to be involved anyway if there is an issue found during the testing. A separate installation testing or a well-documented installation guide may be needed to address the potential installation issues.

This section presents step-by-step procedures for qualifying an application in a non-global zone.

Step 1: Decide on a zone configuration for the qualification testing.

A zone configuration may affect the operation of an application. The following resource types can be configured for a non-global zone:

• inherit-pkg-dir: system directories loop-back mounted to the zone
• fs: file systems to be exposed from the global zone to the non-global zone
• device: device nodes to be exposed to the zone
• net: network interface to be exposed to the zone
• rctl: the name and value pair of a resource control -- see prctl(1)
• pool: name of resource pool that the zone is bound to

The zonecfg(1M) command is used to create and modify these resource types.

The default zone configuration uses the loopback file system lofs(7FS) to mount the global zone's /lib, /platform, /sbin and /usr directories to the non-global zone as read-only file systems. If the application installation needs to write into these directories, the zone administrator should use the following method to export a writable directory to the zone.

global# mkdir /anyDir/myInstallDir  // create the dir to be exported to the zone
global# mkdir /usr/myInstallDir	  // create the mount point
global# zonecfg -z my-zone
zonecfg:my-zone> add fs
zonecfg:my-zone:fs> set dir=/usr/myInstallDir
zonecfg:my-zone:fs> set special=/anyDir/myInstallDir
zonecfg:my-zone:fs> set  type=lofs
zonecfg:my-zone:fs> set options=[rw,nodevices]
zonecfg:my-zone:fs> end

This example creates a default zone configuration and allows /usr/myInstallDir in my-zone to be writable so software can be installed into /usr/myInstallDir.

Step 2: Create a non-global zone.

Here is a quick sample zone configuration where the zone name is my-zone and the IPv4 address is 10.0.0.1:

global# zonecfg -z my-zone
zonecfg:my-zone> create    
zonecfg:my-zone> set zonepath=/export/home/my-zone
zonecfg:my-zone> add net
zonecfg:my-zone:net> set address=10.0.0.1
zonecfg:my-zone:net> set physical=eri0
zonecfg:my-zone:net> end
zonecfg:my-zone:> add fs
zonecfg:my-zone:fs> set dir=/cdrom
zonecfg:my-zone:fs> set special=/cdrom
zonecfg:my-zone:fs> set type=lofs
zonecfg:my-zone:fs> set options=[nodevices]
zonecfg:my-zone:fs> end
zonecfg:my-zone> verify
zonecfg:my-zone> commit
zonecfg:my-zone> ^D

At this point, a zone configuration file, /etc/zones/my-zone.xml, has been created containing the above parameters and several inherited-pkg-dir fields for loopback-mounted file systems.

Once a zone configuration file is established, the global zone administrator uses the zoneadm(1M) command to install and boot the zone:

global# zoneadm -z my-zone install   
global# zoneadm -z my-zone boot 

When a zone is booted for the first time after installation, it will have no internal configuration for naming schemes, no locale or timezone, no root password, and so on. It will be necessary to access the zone's console in order to answer the prompts and to set these up. This should be done using the zlogin(1M) command:

# zlogin -C my-zone

Step 3: Install application in the non-global zone.

At this point, the ISV test engineer should be able to install the ISV application into the non-global zone.

In a typical software installation, a software installation CD/DVD should be exported to the non-global zone. Since vold(1M) does not run in a non-global zone, the test engineer will have to manually mount the CD/DVD. This can be accomplished by loopback mounting the /cdrom directory from the global zone. The example given in step 2 shows how to loopback mount the /cdrom directory from the global zone.

Step 4: Perform qualification testing.

Once the application is successfully installed into the non-global zone, the test engineer can perform the qualification tests as if the application were installed on a regular Solaris system. A non-global zone has more restrictions on an application than the global zone in terms of privileges for accessing system resources and kernel services, device availability, networking capability. Thus a successful qualification test in a non-global zone assures the application will work in the global zone.

Step 5: Handle qualification failures.

In the case of a failure in the non-global zone qualification test, the test engineer should examine the failure before reporting it to the development team. For a failure caused by the zone configuration such as unavailability of a particular device, writing to a read-only file system, or resource constraints, the failure can be corrected with a different zone configuration. However, if the failure is caused by insufficient privileges, this failure can only be fixed by code changes. In such a case, the failure has to be reported to the development team for evaluation. The article "Bringing Your Application Into the Zone" ^[6] in References provides a workaround for the API privilege failure.

Step 6: Perform Operations 2 and 3 (optional).

This operation may not catch the silent errors that might result in degraded performance or missing feature of the application. To ensure maximum application quality in a non-global zone, it is recommended to run srcheck in the global zone to monitor the privilege and device nodes usage (Operation 2) and to scan the source base for the use of non-supported APIs in the application (Operation 3).

Step 1: Install Solaris Ready Test Suite.

After installing Solaris Ready Test Suite, run srcheck in the bin directory. srcheck is a test suite developed for the Solaris Ready program ^[7] to check application compliance and quality running on the Solaris OS. srcheck includes several checks for testing application compliance with the Solaris OS. In regards to the Solaris Zones compliance test, srcheck includes:

srcheck should be invoked before starting normal application testing.

Step 2: Install application in the global zone.

The test engineer installs the application in the normal way.

Step 3: Run srcheck.

The test engineer must run srcheck before starting the application qualification testing. If the qualification testing has performance suites, srcheck can be used along with the performance test suites. However it should be noted that srcheck might impose an overhead on the system, therefore it is not recommended to obtain performance numbers when srcheck is still running. Run the performance test suites with srcheck to understand whether the exercised code will work properly in a non-global zone. If they passed, rerun the tests without srcheck to obtain accurate performance data.

In an example of running srcheck to monitor the commands date, ifconfig, mdb, and drvconfig in the non-global zone my-zone4 for 10 minutes, the input arguments to srcheck look like:

% srcheck -n "My Application Name" -i App_dir -c date,ifconfig \
     -t 600 -z my-zone4

Ten minutes later, /tmp/srcheck.28838/ for the srcheck process ID 28838 is created with a summary output of srcheck in /tmp/srcheck.28838/summary_report.txt.

If any one of the commands date, ifconfig, mdb, or drvconfig is executed in the non-global zone, my-zone4:

• Uses a privilege that is available in a non-global zone, and
• Opens a device node that is not available in the non-global zone.

This will be recorded in /tmp/srcheck.28838/summary_report.txt.

Step 4: Perform qualification testing.

The test engineer performs the qualification tests in the global zone. (srcheck can be used to monitor processes running in a non-global zone. However, it is assumed that the qualification tests are performed in the global zone.)

Step 5: Handle the issues reported by the script.

srcheck places its output in /tmp/srcheck.pidXXX where pidXXX is the process ID of srcheck. A summary report, summary_report.txt, is created in that directory. All issues flagged by srcheck should be reported to the development team. See the article "Bringing Your Application Into the Zone"^[6] in References for a workaround for some of the issues.

% cat / tmp/srcheck.28838/summary_report.txt

******************************************************************************
System:  i86pc
Processor: 2-1792MHz AMD Opteron(tm) Processor 244, Memory: 2048 Megabytes
OS: SunOS xian-60 5.10 Generic, amd64
Date: Mon Jan  9 21:31:07 PST 2006
******************************************************************************
SRcheck command line: /tmp/srcheck/bin/srcheck -n test1 -i /		
export/home/ws/onnv/usr/src/cmd/cmd-inet/ -t 50

Solaris 10 COMPATIBILITY - SUMMARY REPORT

Source code analysis - "c" code:    ISSUES: 24  OCCURRENCES: 192
    details: /tmp/srcheck.7627/private/srcheck_scan/reports/srcheck.pscore_c.log
Source code analysis - "h" code:    ISSUES: 0   OCCURRENCES: 0

Source code analysis - "shell" code:    ISSUES: 2   OCCURRENCES: 2
    details: /tmp/srcheck.7627/private/srcheck_scan/reports/shell_lines.txt
Source code analysis - "perl" code: ISSUES: 15  OCCURRENCES: 15
    details: /tmp/srcheck.7627/private/srcheck_scan/reports/srcheck.perlscan_pl.log
==============================================================================
               	                  appcheck output

	Program Name                Privilege      	Count
           ifconfig      PRIV_SYS_NET_CONFIG      	 1
          drvconfig          PRIV_SYS_CONFIG      	 1
               date            PRIV_SYS_TIME      	 1


	Program Name              Device Node      	Count
          drvconfig /devices/pseudo/devinfo@0:devinfo       1
           ifconfig                 /dev/udp                1
                mdb               /dev/ksyms    	    1

Step 6: Install application in the non-global zone.

Solaris Ready Test Suite is not capable of detecting installation issues. It is, therefore, recommended to perform Step 3 of Section 3.1 to ensure that the application can be installed in a non-global zone.

Step 7: Perform Operation 3 (optional).

This operation catches the zone errors in the code path exercised in the QA test. To ensure maximum code coverage, it is recommended to run srcheck in the global zone to scan the source base for the use of non-supported APIs in the application (Operation 3).

Step 1: Run srcheck.

srcheck parses the application source code in the C, C++, and shell script files of the designated directory to check for the use of the following, which could return an error in a non-global zone:

• APIs
• Device nodes
• Commands

srcheck also runs the ABI checking tool abiscan and checks binary executables and dynamic libraries of third-party vendors for zone compatibility issues.

A typical use of the tool is:

% srcheck -n "My Application Name" -i /home/johndoe/src -t 0

srcheck produces several reports, including a summary report of all issues found.

Step 2: Evaluate the srcheck reports.

The development team should evaluate the srcheck reports to determine whether the issues in these reports could prevent the application from running in a non-global zone. As explained in section 3, some items in the reports may not be real issues. Examples of the functions that may report false positive issues are open(2), socket(2), link(2), unlink(2), and ioctl(2).

Step 3: Install application in the global zone.

The test engineer installs the application in the normal way.

Step 4: Perform qualification testing in the global zone.

The test engineer performs the qualification tests in the normal way.

Step 5: Install application in the non-global zone.

Solaris Ready Test Suite is not capable of detecting installation issues. It is, therefore, recommended to perform Step 3 of Section 3.1 to ensure that the application can be installed in a non-global zone.

Step 6: Perform Operation 2 (optional).

This operation reports many false positives for the system calls link(2), ioctl(2), socket(2), open(2), and unlink(2). To cross check the use of these system calls, it is recommended to run srcheck in the global zone along with the QA test to monitor the privilege and device nodes usage in the application (Operation 2).

Each non-global zone has a security boundary around it. The security boundary is maintained by:

• Reduced process privileges,
• Resource and service virtualization, and
• Inter-zone communication via network only.

The Solaris 10 OS introduces Process Rights Management, which extends the Solaris process model with privilege sets and uses these privileges sets to control the process access of system resources and kernel services. A process can be either of the following:

• Privilege Aware (PA): completely ignores the effective UID.
• Not Privilege Aware (NPA): behaves almost exactly like a traditional process.

If a process is PA, the kernel only checks the process privileges for system operations. If a process is NPA, the kernel checks both UID and process privileges. A process can attempt to become NPA using setpflags(2).

Each privilege set contains zero or more privileges. Each process has four sets of privileges. One of the privilege sets, the Effective (E) privilege set, determines whether a process can use a particular privilege.

These four privilege sets are:

• E, the Effective set: The set of privileges currently in effect
• P, the Permitted set: The maximum set of privileges for the process
• I, the Inheritable set: The set of privileges inherited on exec(2)
• L, the Limit set: The upper bound of the privileges a process and its offspring can obtain

Currently, 48 privileges are defined for a privilege set. privileges(5) lists these privileges and their definitions. ppriv(1) can be used to inspect or modify process privilege sets.

All processes running in a non-global zone have reduced privileges. That means all processes in a non-global zone are constrained by the privilege sets that are assigned to them when the process is created. Table 1 lists the privileges that processes in a non-global zone have. Because of the reduced privileges of a process in a non-global zone, certain system calls may return errors. In most cases, EPERM will be returned for a process that does not possess the privilege. Some system calls that check PRIV_CPC_CPU or PRIV_NET_RAWACCESS may return EACCESS.

It should be noted that only privileged applications in a non-global zone are affected by reduced process privileges. A traditional non-privileged application possesses only five basic privileges as highlighted in bold font in the following table. These five basic privileges are available to the non-global zones.

Table: 1 Solaris Privileges

    All Privileges                   	Zone Privileges
 ===========================           ==============================
     PRIV_CONTRACT_EVENT                PRIV_CONTRACT_EVENT
     PRIV_CONTRACT_OBSERVER             PRIV_CONTRACT_OBSERVER
     PRIV_CPC_CPU
     PRIV_DTRACE_PROC
     PRIV_DTRACE_USER
     PRIV_DTRACE_KERNEL
     PRIV_FILE_CHOWN                    PRIV_FILE_CHOWN
     PRIV_FILE_CHOWN_SELF               PRIV_FILE_CHOWN_SELF
     PRIV_FILE_DAC_EXECUTE              PRIV_FILE_DAC_EXECUTE
     PRIV_FILE_DAC_READ                 PRIV_FILE_DAC_READ
     PRIV_FILE_DAC_SEARCH               PRIV_FILE_DAC_SEARCH
     PRIV_FILE_DAC_WRITE                PRIV_FILE_DAC_WRITE
     PRIV_FILE_LINK_ANY                 PRIV_FILE_LINK_ANY
     PRIV_FILE_OWNER                    PRIV_FILE_OWNER
     PRIV_FILE_SETID                    PRIV_FILE_SETID
     PRIV_IPC_DAC_READ                  PRIV_IPC_DAC_READ
     PRIV_IPC_DAC_WRITE                	PRIV_IPC_DAC_WRITE
     PRIV_IPC_OWNER                     PRIV_IPC_OWNER
     PRIV_NET_ICMPACCESS                PRIV_NET_ICMPACCESS
     PRIV_NET_PRIVADDR                  PRIV_NET_PRIVADDR
     PRIV_NET_RAWACCESS      	    	 
     PRIV_PROC_CHROOT                	PRIV_PROC_CHROOT
     PRIV_PROC_CLOCK_HIGHRES	
     PRIV_PROC_AUDIT                   	PRIV_PROC_AUDIT
     PRIV_PROC_EXEC			PRIV_PROC_EXEC
     PRIV_PROC_FORK			PRIV_PROC_FORK		
     PRIV_PROC_INFO			PRIV_PROC_INFO
     PRIV_PROC_LOCK_MEMORY
     PRIV_PROC_OWNER           		PRIV_PROC_OWNER
     PRIV_PROC_PRIOCNTL
     PRIV_PROC_SESSION			PRIV_PROC_SESSION
     PRIV_PROC_SETID                  	PRIV_PROC_SETID
     PRIV_PROC_TASKID                  	PRIV_PROC_TASKID
     PRIV_PROC_ZONE
     PRIV_SYS_ACCT                     	PRIV_SYS_ACCT
     PRIV_SYS_ADMIN                    	PRIV_SYS_ADMIN
     PRIV_SYS_AUDIT                    	PRIV_SYS_AUDIT
     PRIV_SYS_CONFIG
     PRIV_SYS_DEVICES
     PRIV_SYS_IPC_CONFIG
     PRIV_SYS_LINKDIR
     PRIV_SYS_MOUNT                    	PRIV_SYS_MOUNT
     PRIV_SYS_NET_CONFIG
     PRIV_SYS_NFS                      	PRIV_SYS_NFS
     PRIV_SYS_RESOURCE           	PRIV_SYS_RESOURCE
     PRIV_SYS_SUSER_COMPAT
     PRIV_SYS_TIME

The Solaris Zones feature virtualizes the following resources and services that a process requires to run in an operating environment while its activities are isolated from the processes in other zones:

• Network interfaces
• File systems
• Interprocess communication (IPC)
• Devices
• Process
• Resource management facilities
• Packaging database

The following networking restrictions apply to a non-global zone:

• IPQoS and IPsec configurations, ipqosconf(1M) and ipsecconf(1M), can only be done in the global zone. A zone-specific configuration can be created by specifying a zone's IP address to the configuration.
• Raw access to layers below the transport layer (for example, IP, ARP, and DLPI to the link layer) is not allowed in a non-global zone. Thus, using DLPI to directly communicate with a link layer (NIC device driver) will result in an error. snoop(1M) will not work in a non-global zone because it uses DLPI to directly access interface drivers.
• The following networking features remain as system-wide features that can only be configured by global administrator:
• Routing
• IP Multipathing (IPMP)
• Mobile IP
• DHCP Client
• Network Cache and Accelerator (NCA)
• Networking tuning via /etc/system and ndd(1M)
• IP Filter

Each zone has its own file system name space, although a global zone file system can be shared among other zones. The default zone configuration uses the loopback virtual file system, lofs(7FS), to loopback-mount several global zones' system directories such as /usr, /lib, /platform, and /sbin to the non-global zone. In addition to lofs(7FS), you can also locally mount these in a non-global zone: autofs, tmpfs(7FS), mntfs, ctfs(7FS), procfs, and NFS clients.

It is the basic design principle of Solaris Zones that a process in a zone is only able to use IPC to communicate with other processes in the same zone. For file system-based IPC such as pipes (via fifofs), STREAMS (via namefs), UNIX domain sockets (via sockfs), and POSIX IPC, the unique file system name space of a zone ensures that IPC communication is within a zone.

Other IPCs, such as Solaris doors and System V IPC, have attached a zone ID to the communication objects so processes running in a zone will only be able to access or control objects associated with the same zone.

Devices, in general, are shared resources in a system. To make devices available in a zone, therefore, requires some restrictions so the principle of zone isolation will not be compromised. The /dev directory is heavily restricted because of the following constraints:

• Devices that expose system data are only available in the global zone. Examples of such devices are dtrace(7D), kmem(7D), ksyms(7D), kmdb(7D), trapstat(1M), lockstat(7D), and so on.
• The /dev name space consists of symbolic links (logical paths) to the physical paths in /devices. The /devices name space, which is only available in the global zone, reflects the current state of attached device instances created by the driver. Only the logical path /dev is visible in a non-global zone.
• During a non-global zone bring-up, zoneadmd(1M) creates a zone-specific /dev and, then, loop-back mounts the /dev directory under the non-global zone root. The global administrator uses zonecfg(1M) to specify the devices to appear in a particular zone. The number of /dev entries in a non-global zone is significantly less than the number of /dev entries in a global zone.
• The zone administrator can change device permissions, but cannot create new entries.
• Device number is a system-wide property. A system call -- for example, mknod(2) -- that creates a special file mapping to a particular device number will return an error.
• Solaris Volume Manager metadevices cannot be configured in a non-global zone. However, the global administrator can create a file system on a meta device in the global zone, and then export the file system to a non-global zone.
• The global administrator uses the add device sub-command of zonecfg(1M) to include additional devices in a zone. For example, to add /dev/dsk/c1t1d0s0 device node to the zone, the administrator adds the following lines:

zonecfg:my-zone> add device zonecfg:my-zone:device> set match=/dev/dsk/c1t1d0s0 zonecfg:my-zone:device> end



• Utilities that perform hardware configuration or change the /dev entries will not work in a zone. These utilities include:
• add_drv(1M)/rem_drv(1M)
• modload(1M)/modunload(1M)
• autopush(1M)
• cfgadm(1M)
• devfsadm(1M), drvconfig(1M), disks(1M), tapes(1M), ports(1M), and devlinks(1M)
• Zone Console: The zone console, /dev/zconsole, is implemented by the zcons(7D) driver. Each instance of the zcons driver represents a global-zone/non-global-zone pair. The driver channels I/O from the global zone to the non-global zone, and back. /dev/console, /dev/msglog, /dev/syscon, /dev/sysmsg and /dev/systty are all symbolic links to /dev/zconsole.

A basic principle of the Solaris Zones design is that processes within a non-global zone must not be able to affect or to see the activity of processes running in other zones. Each process is associated with a zone. Restricting process visibility can be enforced by limiting the process ID exposed through proc(4) accesses and its associated utilities, proc(1).

In a zone, the proc(4) file system only exposes the processes of that zone. The /proc file system in a global zone will show all processes running on the system including the processes of all other zones.

Attempts to signal or to control processes in other zones -- for example, via /proc -- will result in an error code or ESRCH (or ENOENT for proc(4) accesses) rather than EPERM. Only the process in the global zone that has the PRIV_PROC_ZONE privilege can signal or control processes in other zones.

Each zone maintains its own package and patch database. A package or a patch can be installed individually in a non-global zone or in all non-global zones from the global zone.

It is recommended to use smpatch(1M) to analyze, download, apply, and remove patches on the global zone and, then, to run showrev(1M) in a non-global zone to get the revision information about patches of the non-global zone. If patch management is necessary, patchadd(1M) and patchrm(1M) can be used to apply and to remove, respectively, patches from the non-global zone.

1. System Administration Guide: Solaris Containers-Resource Management and Solaris Zones from Sun Microsystems, Inc.
2. BigAdmin System Administration Portal - Solaris Zones
3. "Chapter 8: Using Roles and Privileges (Overview)", System Administration Guide: Security Services from Sun Microsystems, Inc.
4. Solaris 10 Reference Manual Collection from Sun Microsystems, Inc.
5. Chien-Hua Yen, Solaris Zones Partitioning Technology, March 2005
6. Paul Lovvik, Joseph Balenzano, Bringing Your Application Into the Zone, Sun Developer Network
7. The Solaris Ready Logo Program
8. Menno Lageman, Solaris Containers - What They Are and How to Use Them (pdf), Sun BluePrints, May 2005
9. OpenSolaris Zones and Containers FAQ, maintained by Jeff Victor, et al.