The known situations that a developer should investigate are as follows:
System calls that change the system time require the PRIV_SYS_TIME privilege. These system calls include adjtime(2), ntp_adjtime(2), and stime(2).
System calls that need to operate on files that have the sticky bit set require the PRIV_SYS_CONFIG privilege. These system calls include chmod(2), creat(2), and open(2).
The ioctl(2) system call requires the PRIV_SYS_NET_CONFIG privilege to be able to unlock an anchor on a STREAMS module.
The link(2) and unlink(2) system calls require the PRIV_SYS_LINKDIR privilege to create a link or unlink a directory in a non-global zone. Applications that install or configure software or that create temporary directories could be affected by this limitation.
The PRIV_PROC_LOCK_MEMORY privilege is required for the mlock(3C), munlock(3C), mlockall(3C), munlockall(3C), and plock(3C) functions and the MC_LOCK, MC_LOCKAS, MC_UNLOCK, and MC_UNLOCKAS flags for the memcntl(2) system. This privilege is a default privilege in a non-global zone. See Privileges in a Non-Global Zone in Creating and Using Oracle Solaris Zones for more information.
The mknod(2) system call requires the PRIV_SYS_DEVICES privilege to create a block (S_IFBLK) or character (S_IFCHAR) special file. This limitation affects applications that need to create device nodes on the fly.
The IPC_SET flag in the msgctl(2) system call requires the PRIV_SYS_IPC_CONFIG privilege to increase the number of message queue bytes. This limitation affects any applications that need to resize the message queue dynamically.
The nice(2) system call requires the PRIV_PROC_PRIOCNTL privilege to change the priority of a process. This privilege is available by default in a non-global zone. Another way to change the priority is to bind the non-global zone in which the application is running to a resource pool, although scheduling processes in that zone is ultimately decided by the Fair Share Scheduler.
The P_ONLINE, P_OFFLINE, P_NOINTR, P_FAULTED, P_SPARE, and PZ-FORCED flags in the p_online(2) system call require the PRIV_SYS_RES_CONFIG privilege to return or change process operational status. This limitation affects applications that need to enable or disable CPUs.
The PC_SETPARMS and PC_SETXPARMS flags in the priocntl(2)system call requires the PRIV_PROC_PRIOCNTL privilege to change the scheduling parameters of a lightweight process (LWP).
System calls that need to manage processor sets (psets), including binding LWPs to psets and setting pset attributes require the PRIV_SYS_RES_CONFIG privilege. This limitation affects the following system calls: pset_assign(2), pset_bind(2), pset_create(2), pset_destroy(2), and pset_setattr(2).
The SHM_LOCK and SHM_UNLOCK flags in the shmctl(2) system call require the PRIV_PROC_LOCK_MEMORY privilege to share memory control operations. If the application is locking memory for performance purposes, using the intimate shared memory (ISM) feature provides a potential workaround.
The swapctl(2)system call requires the PRIV_SYS_CONFIG privilege to add or remove swapping resources. This limitation affects installation and configuration software.
The uadmin(2) system call requires the PRIV_SYS_CONFIG privilege to use the A_REMOUNT, A_FREEZE, A_DUMP, and AD_IBOOT commands. This limitation affects applications that need to force crash dumps under certain circumstances.
The clock-settime(3C) function requires the PRIV_SYS_TIME privilege to set the CLOCK_REALTIME and CLOCK_HIRES clocks.
The cpc_bind_cpu(3CPC) function requires the PRIV_CPC_CPU privilege to bind request sets to hardware counters. As a workaround, the cpc_bind_curlwp(3CPC) function can be used to monitor CPU counters for the LWP in question.
The pthread_attr_setschedparam(3C) function requires the PRIV_PROC_PRIOCNTL privilege to change the underlying scheduling policy and parameters for a thread.
The timer_create(3C) function requires the PRIV_PROC_CLOCK_HIGHRES privilege to create a timer using the high-resolution system clock.
The APIs that are provided by the following list of libraries are not supported in a non-global zone. The shared objects are present in the zone's /usr/lib directory, so no link time errors occur if your code includes references to these libraries. You can inspect your make files to determine if your application has explicit bindings to any of these libraries and use pmap(1) while the application is executing to verify that none of these libraries are dynamically loaded.
Zones have a restricted set of devices, consisting primarily of pseudo devices that form part of the Oracle Solaris programming API. These pseudo devices include /dev/null, /dev/zero, /dev/poll, /dev/random, /dev/tcp, and so on. Physical devices are not directly accessible from within a zone unless the device has been configured by a system administrator. Since devices, in general, are shared resources in a system, to make devices available in a zone requires some restrictions so system security will not be compromised, as follows:
The /dev name space consists of symbolic links, that is, logical paths, to the physical paths in /devices. The /devices name space, which is available only in the global zone, reflects the current state of attached device instances that have been created by the driver. Only the logical path /dev is visible in a non-global zone.
Processes within a non-global zone cannot create new device nodes. For example, mknod(2) cannot create special files in a non-global zone. The creat(2), link(2), mkdir(2), rename(2), symlink(2), and unlink(2) system calls fail with EACCES if a file in /dev is specified. You can create a symbolic link to an entry in /dev, but that link cannot be created in /dev.
Devices that expose system data are only available in the global zone. Examples of such devices include dtrace(7D), kmem(7D), kmdb(7d), ksyms(7D), lockstat(7D), and trapstat(1M).
The /dev name space consists of device nodes made up of a default, “safe” set of drivers as well as device nodes that have been specified for the zone by the zonecfg(1M) command.