NAME | SYNOPSIS | DESCRIPTION | ERRORS | DEFINITIONS
#include <errno.h>
This section describes all of the system calls in the Trusted Solaris environment.
Trusted Solaris system calls are one of the following:
Calls that are unique to and originate in the Trusted Solaris environment, such as secconf(2). The secconf() system call allows processes to determine the value of a configurable security-related system variable, such as the variable that hides upgraded file names when set.
SunOS
5.8 system calls that have been modified to work within Trusted Solaris security policy, such as link(2). Man pages for modified
system calls have been rewritten to remove information that is not accurate for how the system call behaves within the Trusted Solaris environment. Modified man pages also have added descriptions for new features and arguments.
SunOS
5.8 system calls that remain unchanged from the Solaris 8 release, such as exit(2).
The printed Trusted Solaris 8 4/01 Reference Manual includes only those system calls that have been modified or originate in the Trusted Solaris environment. Printed versions of unchanged SunOS
5.8 man pages are found in the SunOS 5.8 Reference Manual.
See Trusted Solaris Manual Page Display in Intro(1) for more discussion.
When a man page for a system call states that the calling process must have or must assert a specified privilege or privileges, that means:
The privilege(s) must be made available as allowed privileges on the executable, and
The privileges must be made available to the effective privilege set of the process in either of these two ways:
By inheritance from the parent process, or
As forced privileges assigned to the executable program.
Most of these calls return one or more error conditions. An error condition is indicated by an otherwise impossible return value. This is almost always -1 or the null pointer; the individual descriptions specify the details. An error number is also made available in the external variable errno, which is not cleared on successful calls, so it should be tested only after an error has been indicated.
In the case of multithreaded applications, the _REENTRANT flag must be defined on the command line at compilation time (-D_REENTRANT). When the _REENTRANT flag is defined, errno becomes a macro which enables each thread to have its own errno. This errno macro can be used on either side of the assignment, just as if it were a variable.
Applications should use bound threads rather than the _lwp_*() functions (see thr_create(3THR)). Using LWPs (lightweight processes) directly is not advised because libraries are only safe to use with threads, not LWPs.
Each system call description attempts to list all possible error numbers. The following is a complete list of the error numbers and their names as defined in <errno.h>.
Appropriate privilege not asserted
Typically this error indicates an attempt to modify a file in some way forbidden except to its owner or a process with the appropriate privilege. It is also returned for attempts by ordinary users to do things that always require a privilege. See Privilege in the DEFINITIONS section.
No such file or directory
A file name is specified and the file should exist but doesn't, or one of the directories in a path name does not exist.
No such process, LWP, or thread
No process can be found in the system that corresponds to the specified PID, LWPID_t, or thread_t.
Interrupted system call
An asynchronous signal (such as interrupt or quit), which the user has elected to catch, occurred during a system service function. If execution is resumed after processing the signal, it will appear as if the interrupted function call returned this error condition.
In a multithreaded application, EINTR may be returned whenever another thread or LWP calls fork(2).
I/O error
Some physical I/O error has occurred. This error may in some cases occur on a call following the one to which it actually applies.
No such device or address
I/O on a special file refers to a subdevice which does not exist, or exists beyond the limit of the device. It may also occur when, for example, a tape drive is not on-line or no disk pack is loaded on a drive.
Arg list too long
An argument list longer than ARG_MAX bytes is presented to a member of the exec family of functions (see exec(2)). The argument list limit is the sum of the size of the argument list plus the size of the environment's exported shell variables.
Exec format error
A request is made to execute a file which, although it has the appropriate permissions, does not start with a valid format (see a.out(4)).
Bad file number
Either a file descriptor refers to no open file, or a read(2) (respectively, write(2)) request is made to a file that is open only for writing (respectively, reading).
No child processes
A wait(2) function was executed by a process that had no existing or unwaited-for child processes.
No more processes, or no more LWPs
For example, the fork(2) function failed because the system's process table is full or the user is not allowed to create any more processes, or a call failed because of insufficient memory or swap space.
Not enough space
During execution of brk() or sbrk() (see brk(2)), or one of the exec family of functions, a program asks for more space than the system is able to supply. This is not a temporary condition; the maximum size is a system parameter. On some architectures, the error may also occur if the arrangement of text, data, and stack segments requires too many segmentation registers, or if there is not enough swap space during the fork(2) function. If this error occurs on a resource associated with Remote File Sharing (RFS), it indicates a memory depletion which may be temporary, dependent on system activity at the time the call was invoked.
Permission denied
An attempt was made to access a file in a way forbidden by the Trusted Solaris security policy. This type of failure due to DAC or MAC restrictions may be bypassed at the discretion of the security administrator if the appropriate override privilege(s) are made available to be asserted by the calling process (which privilege to use depends on the type of access being denied). See Discretionary Access Control, File Access, Mandatory Access Control, Privilege, and Security Policy in the DEFINITIONS section.
Bad address
The system encountered a hardware fault in attempting to use an argument of a routine. For example, errno potentially may be set to EFAULT any time a routine that takes a pointer argument is passed an invalid address, if the system can detect the condition. Because systems will differ in their ability to reliably detect a bad address, on some implementations passing a bad address to a routine will result in undefined behavior.
Block device required
A non-block device or file was mentioned where a block device was required (for example, in a call to the mount(2) function).
Device busy
An attempt was made to mount a device that was already mounted or an attempt was made to unmount a device on which there is an active file (open file, current directory, mounted-on file, active text segment). It will also occur if an attempt is made to enable accounting when it is already enabled. The device or resource is currently unavailable. EBUSY is also used by mutexes, semaphores, condition variables, and r/w locks, to indicate that a lock is held, and by the processor control function P_ONLINE.
File exists
An existing file was mentioned in an inappropriate context (for example, call to the link(2) function).
Cross-device link
A hard link to a file on another device was attempted.
No such device
An attempt was made to apply an inappropriate operation to a device (for example, read a write-only device).
Not a directory
A non-directory was specified where a directory is required (for example, in a path prefix or as an argument to the chdir(2) function).
Is a directory
An attempt was made to write on a directory.
Invalid argument
An invalid argument was specified (for example, unmounting a non-mounted device), mentioning an undefined signal in a call to the signal(3C) or kill(2) function.
File table overflow
The system file table is full (that is, SYS_OPEN files are open, and temporarily no more files can be opened).
Too many open files
No process may have more than OPEN_MAX file descriptors open at a time.
Inappropriate ioctl for device
A call was made to the ioctl(2) function specifying a file that is not a special character device.
Text file busy (obselete)
An attempt was made to execute a pure-procedure program that is currently open for writing. Also an attempt to open for writing or to remove a pure-procedure program that is being executed. (This message is obsolete.)
File too large
The size of the file exceeded the limit specified by resource RLIMIT_FSIZE; the file size exceeds the maximum supported by the file system; or the file size exceeds the offset maximum of the file descriptor. See the File Descriptor subsection of the DEFINITIONS section below.
No space left on device
While writing an ordinary file or creating a directory entry, there is no free space left on the device. In the fcntl(2) function, the setting or removing of record locks on a file cannot be accomplished because there are no more record entries left on the system.
Illegal seek
A call to the lseek(2) function was issued to a pipe.
Read-only file system
An attempt to modify a file or directory was made on a device mounted read-only.
Too many links
An attempt to make more than the maximum number of links, LINK_MAX, to a file.
Broken pipe
A write on a pipe for which there is no process to read the data. This condition normally generates a signal; the error is returned if the signal is ignored.
Math arguement out of domain of func
The argument of a function in the math package (3M) is out of the domain of the function.
Math result not representable
The value of a function in the math package (3M) is not representable within machine precision.
No message of desired type
An attempt was made to receive a message of a type that does not exist on the specified message queue (see msgrcv(2)).
Identifier removed
This error is returned to processes that resume execution due to the removal of an identifier from the file system's name space (see msgctl(2), semctl(2), and shmctl(2)).
Channel number out of range
Level 2 not synchronized
Level 3 halted
Level 3 reset
Link number out of range
Protocol driver not attached
No CSI structure available
Level 2 halted
Deadlock condition
A deadlock situation was detected and avoided. This error pertains to file and record locking, and also applies to mutexes, semaphores, condition variables, and r/w locks.
No record locks available
There are no more locks available. The system lock table is full (see fcntl(2)).
Operation canceled
The associated asynchronous operation was canceled before completion.
Not supported
This version of the system does not support this feature. Future versions of the system may provide support.
Disc quota exceeded
A write(2) to an ordinary file, the creation of a directory or symbolic link, or the creation of a directory entry failed because the user's quota of disk blocks was exhausted, or the allocation of an inode for a newly created file failed because the user's quota of inodes was exhausted.
Reserved
Device not a stream
A putmsg(2) or getmsg(2) call was attempted on a file descriptor that is not a STREAMS device.
No data available
Timer expired
The timer set for a STREAMS ioctl(2) call has expired. The cause of this error is device-specific and could indicate either a hardware or software failure, or perhaps a timeout value that is too short for the specific operation. The status of the ioctl() operation is indeterminate. This is also returned in the case of _lwp_cond_timedwait(2) or _lwp_cond_wait(2).
Out of stream resources
During a STREAMS open(2) call, either no STREAMS queues or no STREAMS head data structures were available. This is a temporary condition; one may recover from it if other processes release resources.
Machine is not on the network
This error is Remote File Sharing (RFS) specific. It occurs when users try to advertise, unadvertise, mount, or unmount remote resources while the machine has not done the proper startup to connect to the network.
Package not installed
This error occurs when users attempt to use a call from a package which has not been installed.
Object is remote
This error is RFS-specific. It occurs when users try to advertise a resource which is not on the local machine, or try to mount/unmount a device (or pathname) that is on a remote machine.
Link has been severed
This error is RFS-specific. It occurs when the link (virtual circuit) connecting to a remote machine is gone.
Advertise error
This error is RFS-specific. It occurs when users try to advertise a resource which has been advertised already, or try to stop RFS while there are resources still advertised, or try to force unmount a resource when it is still advertised.
Srmount error
This error is RFS-specific. It occurs when an attempt is made to stop RFS while resources are still mounted by remote machines, or when a resource is readvertised with a client list that does not include a remote machine that currently has the resource mounted.
Communication error on send
This error is RFS-specific. It occurs when the current process is waiting for a message from a remote machine, and the virtual circuit fails.
Protocol error
Some protocol error occurred. This error is device-specific, but is generally not related to a hardware failure.
Error 76
This error is RFS-specific. A way for the server to tell the client that a process has transferred back from mount point.
Not a data message
During a read(2), getmsg(2), or ioctl(2) I_RECVFD call to a STREAMS device, something has come to the head of the queue that can not be processed. That something depends on the call:
control information or passed file descriptor.
passed file descriptor.
control or data information.
File name too long
The length of the path argument exceeds PATH_MAX, or the length of a path component exceeds NAME_MAX while _POSIX_NO_TRUNC is in effect; see limits(4).
Value too large for defined data type.
Name not unique on network
Given log name not unique.
File descriptor in bad state
Either a file descriptor refers to no open file or a read request was made to a file that is open only for writing.
Remote address changed
Cannot access a needed share library
Trying to exec an a.out that requires a static shared library and the static shared library does not exist or the user does not have permission to use it.
Accessing a corrupted shared library
Trying to exec an a.out that requires a static shared library (to be linked in) and exec could not load the static shared library. The static shared library is probably corrupted.
.lib section in a.out corrupted
Trying to exec an a.out that requires a static shared library (to be linked in) and there was erroneous data in the .lib section of the a.out. The .lib section tells exec what static shared libraries are needed. The a.out is probably corrupted.
Attempting to link in more shared libraries than system limit
Trying to exec an a.out that requires more static shared libraries than is allowed on the current configuration of the system. See NFS Administration Guide
Cannot exec a shared library directly
Attempting to exec a shared library directly.
Error 88
Illegal byte sequence. Handle multiple characters as a single character.
Operation not applicable
Number of symbolic links encountered during path name traversal exceeds MAXSYMLINKS
Restartable system call
Interrupted system call should be restarted.
If pipe/FIFO, don't sleep in stream head
Streams pipe error (not externally visible).
Directory not empty
Too many users
Socket operation on non-socket
Destination address required
A required address was omitted from an operation on a transport endpoint. Destination address required.
Message too long
A message sent on a transport provider was larger than the internal message buffer or some other network limit.
Protocol wrong type for socket
A protocol was specified that does not support the semantics of the socket type requested.
Protocol not available
A bad option or level was specified when getting or setting options for a protocol.
Protocol not supported
The protocol has not been configured into the system or no implementation for it exists.
Socket type not supported
The support for the socket type has not been configured into the system or no implementation for it exists.
Operation not supported on transport endpoint
For example, trying to accept a connection on a datagram transport endpoint.
Protocol family not supported
The protocol family has not been configured into the system or no implementation for it exists. Used for the Internet protocols.
Address family not supported by protocol family
An address incompatible with the requested protocol was used.
Address already in use
User attempted to use an address already in use, and the protocol does not allow this.
Cannot assign requested address
Results from an attempt to create a transport endpoint with an address not on the current machine.
Network is down
Operation encountered a dead network.
Network is unreachable
Operation was attempted to an unreachable network.
Network dropped connection because of reset
The host you were connected to crashed and rebooted.
Software caused connection abort
A connection abort was caused internal to your host machine.
Connection reset by peer
A connection was forcibly closed by a peer. This normally results from a loss of the connection on the remote host due to a timeout or a reboot.
No buffer space available
An operation on a transport endpoint or pipe was not performed because the system lacked sufficient buffer space or because a queue was full.
Transport endpoint is already connected
A connect request was made on an already connected transport endpoint; or, a sendto(3SOCKET) or sendmsg(3SOCKET) request on a connected transport endpoint specified a destination when already connected.
Transport endpoint is not connected
A request to send or receive data was disallowed because the transport endpoint is not connected and (when sending a datagram) no address was supplied.
Cannot send after transport endpoint shutdown
A request to send data was disallowed because the transport endpoint has already been shut down.
Too many references: cannot splice
Connection timed out
A connect(3SOCKET) or send(3SOCKET) request failed because the connected party did not properly respond after a period of time; or a write(2) or fsync(3C) request failed because a file is on an NFS file system mounted with the soft option.
Connection refused
No connection could be made because the target machine actively refused it. This usually results from trying to connect to a service that is inactive on the remote host.
Host is down
A transport provider operation failed because the destination host was down.
No route to host
A transport provider operation was attempted to an unreachable host.
Operation already in progress
An operation was attempted on a non-blocking object that already had an operation in progress.
Operation now in progress
An operation that takes a long time to complete (such as a connect()) was attempted on a non-blocking object.
Stale NFS file handle
Created for compatability purposes, it masks out any existing ACL entries without destroying them when chmod(1) changes permissions on a file or directory. The masked names can then later be restored if chmod is run again to restore the original permissions.
A type of discretionary access control based on a list of entries that the owner can specify for a file or directory. The access control list (ACL) restricts or permits access to any number of individuals and groups, allowing finer-grained control than provided by the standard UNIX permission bits.
Actually not a range, but a set made up of labels. See user accreditation range and system accreditation range for more about the two types of accreditation ranges in the Trusted Solaris environment.
Any process group that is not the foreground process group of a session that has established a connection with a controlling terminal.
A wrapper structure for a sensitivity label that contains other internal and obsolete information. This structure is part of the Trusted Solaris ABI.
The hierarchical portion of a sensitivity label or clearance, each of which has only one classification. Each classification has an external name (text string) and an internal number (integer), with the lowest number assigned to the lowest classification and the other numbers assigned to the rest of the classifications in a hierarchical relationship. In a sensitivity label assigned to a file or directory, a classification indicates a relative level of protection based on the sensitivity of the information contained in the file or directory. In a clearance assigned to a user and that user's processes, a classification indicates a level of trust.
Each process has a clearance associated with it. A clearance consists of a classification and a set of compartments. It is similar to a sensitivity label. A process' clearance is an upper bound on the labels to which the process has access. A process can neither set its sensitivity label to a label that dominates its clearance, nor access an object (file or other process) whose sensitivity label dominates the process clearance.
A word associated with one or more compartment bits that may be defined in the label_encodings(4) file to be part of a sensitivity label or clearance. Compartments represent areas of interest or work groups associated with the labels that contain compartments and are used in MAC decisions. Compartments have no intrinsic ordering; however, the label_encodings file can impose constraints that may be hierarchical on the allowable combinations of compartments with each other and with classifications.
A session leader that established a connection to a controlling terminal.
A terminal that is associated with a session. Each session may have, at most, one controlling terminal associated with it and a controlling terminal may be associated with only one session. Certain input sequences from the controlling terminal cause signals to be sent to process groups in the session associated with the controlling terminal; see termio(7I).
Device objects include printers, workstations, tape drives, floppy drives, audio devices, and internal pseudo terminal devices. See mandatory access control for definitions of MAC policy. Devices are subject to the read-equal-write-equal policy.
Directories organize files into a hierarchical system where directories are the nodes in the hierarchy. A directory is a file that catalogs the list of files, including directories (sub-directories), that are directly beneath it in the hierarchy. Entries in a directory file are called links. A link associates a file identifier with a filename. By convention, a directory contains at least two links, . (dot) and .. (dot-dot). The link called dot refers to the directory itself while dot-dot refers to its parent directory. The root directory, which is the top-most node of the hierarchy, has itself as its parent directory. The pathname of the root directory is / and the parent directory of the root directory is /.
The type of access granted or denied by the owner of a file or directory at the discretion of the owner. The Trusted Solaris environment provides two kinds of discretionary access (DAC) controls, permission bits and access control lists.
When two labels of any type (sensitivity label or clearance) are compared and neither of the two labels dominates the other, the labels are said to be disjoint. Information flow between disjoint labels is considered to be a downgrade.
When any type of label (sensitivity label or clearance) has a security level equal to or greater than the security level of another label to which it is being compared, the first label is said to dominate the second. The classification of the dominant label must equal or be higher than the classification of the second label, and the dominant label must include all the words (compartments and markings, if present) in the other label. Sensitivity labels are compared for dominance when MAC decisions are being made. See strictly dominate and disjoint.
In a stream, the direction from stream head to driver.
In a stream, the driver provides the interface between peripheral hardware and the stream. A driver can also be a pseudo-driver, such as a multiplexor or log driver (see log(7D)), which is not associated with a hardware device.
An active process has an effective user ID and an effective group ID that are used to determine file access permissions (see below). The effective user ID and effective group ID are equal to the process's real user ID and real group ID, respectively, unless the process or one of its ancestors evolved from a file that had the set-user-ID bit or set-group-ID bit set (see exec(2)).
Even though, strictly speaking, files, directories, devices and other objects are treated as files in the UNIX system, only the access rules for file system objects are described in this section. Because files, directories, and devices have slightly different mandatory access rules, these rules are separately described. See process objects, System V IPC objects, STREAMS objects, network endpoint objects, device objects, and X window objects for the rules that apply to these other types of objects.
A file, directory, or device may be accessed in three ways:
The name of the file, directory, or device may be viewed,
The contents or the attributes of the file, directory, or device may be viewed, or
The contents or the attributes of the file, directory, or device may be modified.
In the Trusted Solaris environment, each of these types of access is granted or denied based on whether certain discretionary access control checks (described in File Access Permissions) and mandatory access control checks have been passed.
All types of access require that the sensitivity label of the process dominates the sensitivity label of all directories in the path prefix and that the owner of the process has discretionary access for each directory in the path prefix. View access to the name of the file, directory, or device requires only that this part of the check is passed (unless the system is configured to hide upgraded names).
For view access (read access) to the contents or attributes of a file or directory, the process' sensitivity label must dominate the sensitivity label of the file or directory. For view access to the contents of a device (for example, so you can read information on a tape in a tape drive), the process' sensitivity label must be equal to the sensitivity label of the device. The owner of the process also must have discretionary read access to the file, directory, or device.
For a process to write a file or to modify its attributes, the sensitivity label of the file must dominate the sensitivity label of the process and must be dominated by the process' clearance. (See process clearance.) For a process to write into a directory (to create a file or a symbolic link) the label of the process must equal the sensitivity label of the directory. For a process to write to a device (for example, store information on a tape in a tape drive), the sensitivity label of the process must equal the sensitivity label of the device. The security policy for device files can differ from the policy for regular files based on how the policy is defined in the device_policy(4) file, which can be changed by the security administrator. The owner of the process must have discretionary write access to the file, directory, or device.
For each type of failure of a MAC or DAC check, a specific override privilege may be asserted by the process, depending on the type of access being denied. See process privilege sets, and inheritable privileges.
These conditions and the listed override privileges apply to any type of access:
If the sensitivity label of the process does not dominate the sensitivity label of a directory in the path prefix, then the process must assert the privilege to search up (search a directory whose sensitivity label dominates the process' sensitivity label), which is PRIV_FILE_MAC_SEARCH
.
If the user on whose behalf the process is being executed does not assert discretionary search permission for a directory in the path prefix, then the process must have the privilege to override DAC search restrictions when accessing a directory, which is PRIV_FILE_DAC_SEARCH
.
These conditions and the listed override privileges apply to view (read) access to a file or directory or to its attributes:
If the sensitivity label of the process does not dominate the sensitivity label of the file or directory, then the process must assert the privilege to override MAC read restrictions, which is PRIV_FILE_MAC_READ
.
If the user on whose behalf the process is being executed does not have discretionary read permission for the file or directory, then the process must assert the privilege to override DAC read restrictions, which is PRIV_FILE_DAC_READ
.
These conditions and the listed override privileges apply to modify (write) access to a file or directory or to its attributes:
If the sensitivity label of the file does not dominate or if the sensitivity of the directory or device does not equal the sensitivity label of the process, and if the sensitivity label of the file, directory, or device is not dominated by the process' clearance, the process must assert
the privilege that overrides MAC write restrictions, allowing the user to write up and to write above the process' clearance, which is PRIV_FILE_MAC_WRITE
.
If the user on whose behalf the process is being executed does not have discretionary write permission for the file or directory, then the process must assert the privilege to override DAC write restrictions, which is PRIV_FILE_DAC_WRITE
.
Read, write, and execute/search permissions for a file are granted to a process if one or more of the following are true:
If the effective UID of the process matches the UID of the file, access is granted if allowed by the file's "owner" permission set.
If the effective UID of the process matches an ACL user entry, access is granted if allowed by the ACL entry and the ACL mask.
If the effective GID of the process (or one of its supplemental groups) matches the GID of the file or the group ID of any ACL group entry, a permission set is computed as the inclusive OR of all matching group permission sets, specified as follows:
If the effective GID of the process (or one of its supplemental groups) matches the GID of the file and there is no owning group ACL entry for the file, the "group" permission set is considered a matching group permission set.
If the effective GID of the process (or one of its supplemental groups) matches the GID of the file and there is an owning group ACL entry for the file, the permissions set of that ACL entry is considered a matching group permission set.
If the effective GID of the process (or one of its supplemental groups) matches an ACL group entry, the permission set of that ACL entry is considered a matching group permission set.
If none of the preceding cases applies, access is granted if allowed by the file's "other" permission set and the ACL mask, if any.
A process is granted access if it satisfies the appropriate test above or if it asserts the DAC override privilege corresponding to the desired operation. Otherwise, access is denied.
A file descriptor is a small integer used to perform I/O on a file. The value of a file descriptor is from 0 to (NOFILES-1). A process may have no more than NOFILES file descriptors open simultaneously. A file descriptor is returned by calls such as open(2) or pipe(2). The file descriptor is used as an argument by calls such as read(2), write(2), ioctl(2), and close(2).
Each file descriptor has a corresponding offset maximum. For regular files that were opened without setting the O_LARGEFILE flag, the offset maximum is 2 Gbyte - 1 byte (231 -1 bytes). For regular files that were opened with the O_LARGEFILE flag set, the offset maximum is 263 -1 bytes.
Names consisting of 1 to NAME_MAX characters may be used to name an ordinary file, special file or directory.
These characters may be selected from the set of all character values excluding \0 (null) and the ASCII code for / (slash).
Note that it is generally unwise to use *, ?, [, or ] as part of file names because of the special meaning attached to these characters by the shell (see sh(1), csh(1), and ksh(1)). Although permitted, the use of unprintable characters in file names should be avoided.
A file name is sometimes referred to as a pathname component. The interpretation of a pathname component is dependent on the values of NAME_MAX and _POSIX_NO_TRUNC associated with the path prefix of that component. If any pathname component is longer than NAME_MAX and _POSIX_NO_TRUNC is in effect for the path prefix of that component (see fpathconf(2) and limits(4)), it shall be considered an error condition in that implementation. Otherwise, the implementation shall use the first NAME_MAX bytes of the pathname component.
These sets consist of the allowed and forced privileges specified for use by executable files (programs). The allowed set limits which privileges a process can use, whether the privileges are forced on the executable file or inherited (see inheritable privileges). Any privileges in the forced privilege set are available to any process that invokes the program, as long as they are also in the allowed set.
File-system objects include files (regular files, process files, and device-special files), directories, symbolic links, FIFOs (named pipes), pipes, and UNIX domain socket rendezvous. See mandatory access control for definitions of the MAC policies. See File Access for the MAC rules that apply to regular files, device files, symbolic links, and directories. The policies for the remaining file objects are as follows. UNIX domain socket rendezvous and FIFOs (named pipes) are subject to the write up read down policy. Pipes are subject to the read-equal-write-equal policy.
Each session that has established a connection with a controlling terminal will distinguish one process group of the session as the foreground process group of the controlling terminal. This group has certain privileges when accessing its controlling terminal that are denied to background process groups.
The privileges that a process can pass to a program across an execve(2) without their being affected by the new program's forced or allowed privilege sets. (A child process created through a fork(2) receives all of a parent process` privilege sets with no change.) When a new program is executed by a process, the inheritable set of the process is set to be equal to the inheritable set of the old program: I[process]=I[program]. The inheritable set is not affected by the forced or allowed privileges on the currently executing program, which allows allows privileges to be passed from programs that cannot use them to programs that can.
Maximum number of entries in a struct iovec array.
A security identifier assigned to an object based on the level of protection it needs and to a process based on the degree of trust afforded to the user on whose behalf the process is running.
A set of sensitivity labels assigned to allocatable devices, commands and file systems, specified by designating a maximum label and a minimum label. For allocatable devices, the minimum and maximum labels limit the sensitivity labels at which devices may be allocated. See allocate(1). For commands, the minimum and maximum labels limit the sensitivity labels at which the command may be executed. For file systems, the minimum and maximum labels limit the sensitivity labels at which information may be stored on each file system.
The label view process attribute flags control the translation and display of the internal admin low and admin high labels. A value of External specifies that the admin low and admin high labels are mapped to the lowest and highest labels defined in the label_encodings(4) file. A value
of Internal specifies that the admin low and admin high labels are translated to the respective strings specified in the label_encodings file. If no such names are specified, the strings ADMIN_LOW
and ADMIN_HIGH
are used. If no value is set, the default label view specified in the label_encodings file is used.
These fifteen-bit flags support the GFI FLAGS= option in the label_encodings(4) file, which allows the use of these flags by applications written to use them. These flags are viewable and modifiable only by a trusted path process.
The braces notation, {LIMIT}, is used to denote a magnitude limitation imposed by the implementation. This indicates a value which may be defined by a header file (without the braces), or the actual value may be obtained at runtime by a call to the configuration inquiry pathconf(2) with the name argument _PC_LIMIT.
A type of control based on comparing the sensitivity label of an object to the sensitivity label of the process that is trying to access the object. The MAC policies that apply to various types of objects are read equal, write equal, read down, and write up. (See the individual definitions for each object type for the policy that applies.) When the read equal policy applies, an object may be accessed for reading only when the sensitivity label of the process is equal to the sensitivity label of the object. When the write equal policy applies, an object may be accessed for writing only when the sensitivity label of the process is equal to the sensitivity label of the object. When the write up policy applies, an object may be accessed for writing only when the sensitivity label of the process is dominated by the sensitivity label of the object, hence the process "writes up" to the object. The write up policy also includes write-equal. When the read down policy applies, an object may be accessed for reading only when the sensitivity label of the process dominates the sensitivity label of the object, hence the process "reads down" to the object. The read-down policy also includes read-equal.
The file mode creation mask of the process used during any create function calls to turn off permission bits in the mode argument supplied. Bit positions that are set in umask(cmask) are cleared in the mode of the created file.
In a stream, one or more blocks of data or information, with associated STREAMS control structures. Messages can be of several defined types, which identify the message contents. Messages are the only means of transferring data and communicating within a stream.
In a stream, a linked list of messages awaiting processing by a module or driver.
A message queue identifier (msqid) is a unique positive integer created by a msgget(2) call. Each msqid has a message queue and a data structure associated with it. The data structure is referred to as msqid_ds and contains the following members:
struct ipc_perm msg_perm; struct msg *msg_first; struct msg *msg_last; ulong_t msg_cbytes; ulong_t msg_qnum; ulong_t msg_qbytes; pid_t msg_lspid; pid_t msg_lrpid; time_t msg_stime; time_t msg_rtime; time_t msg_ctime;
The following are descriptions of the msqid_ds structure members:
The msg_perm member is an ipc_perm structure that specifies the message operation permission (see below). This structure includes the following members:
uid_t cuid; /* creator user id */ gid_t cgid; /* creator group id */ uid_t uid; /* user id */ gid_t gid; /* group id */ mode_t mode; /* r/w permission */ ulong_t seq; /* slot usage sequence # */ key_t key; /* key */
The *msg_first member is a pointer to the first message on the queue.
The *msg_last member is a pointer to the last message on the queue.
The msg_cbytes member is the current number of bytes on the queue.
The msg_qnum member is the number of messages currently on the queue.
The msg_qbytes member is the maximum number of bytes allowed on the queue.
The msg_lspid member is the process ID of the last process that performed a msgsnd() operation.
The msg_lrpid member is the process id of the last process that performed a msgrcv() operation.
The msg_stime member is the time of the last msgsnd() operation.
The msg_rtime member is the time of the last msgrcv() operation.
The msg_ctime member is the time of the last msgctl() operation that changed a member of the above structure.
In the msgctl(2), msgget(2), msgrcv(2), and msgsnd(2) function descriptions, the permission required for an operation is given as {token}, where token is the type of permission needed, interpreted as follows:
00400 READ by user 00200 WRITE by user 00040 READ by group 00020 WRITE by group 00004 READ by others 00002 WRITE by others
Read and write permissions on a msqid are granted to a process if the read-equal-write-equal mandatory access control check is passed or if the process asserts the appropriate override privilege (either PRIV_IPC_MAC_READ
or PRIV_IPC_MAC_WRITE
), and if one of the following tests is true:
The effective user ID of the process matches msg_perm.cuid or msg_perm.uid in the data structure associated with msqid and the appropriate bit of the "user" portion (0600) of msg_perm.mode is set.
Any group ID in the process credentials from the set (cr_gid, cr_groups) matches msg_perm.cgid or msg_perm.gid and the appropriate bit of the "group" portion (060) of msg_perm.mode is set.
The appropriate bit of the "other" portion (006) of msg_perm.mode is set.
The process has asserted the appropriate DAC privilege, either PRIV_FILE_DAC_READ
or PRIV_FILE_DAC_WRITE
.
Otherwise, the corresponding permissions are denied.
A module is an entity containing processing routines for input and output data. It always exists in the middle of a stream, between the stream's head and a driver. A module is the STREAMS counterpart to the commands in a shell pipeline except that a module contains a pair of functions which allow independent bidirectional (downstream and upstream) data flow and processing.
A directory in which information at differing sensitivity labels is maintained in separate subdirectories called single-level directories (SLDs), while appearing to most interfaces to be a single directory under a single name. In the Trusted Solaris environment, directories that are used by multiple standard applications to store files at varying labels, such as the /tmp directory, /var/spool/mail, and users' $HOME directories are set up to be MLDs. A process can access an MLD two ways: either by using pathname translation, or by using the adorned name. When a process refers to an MLD without the adorned name, the Trusted Solaris process transparently extends the reference to the SLD that corresponds to the process' sensitivity label. If the process is creating a file and if the correct SLD does not already exist, the Trusted Solaris process creates the SLD and assigns it the process' sensitivity label so that the correct single-level directory exists for the file. If the process wants to access the MLD directly, it should use the the MLD adornment on the final component of the path. The text string .MLD. is the default adornment. The adornment is a file system attribute that may be changed using setfsattr(1M). Use of the adornment allows programs to refer directly to the MLD instead of to the SLD that has the same SL as the process.
A multiplexor is a driver that allows streams associated with several user processes to be connected to a single driver, or several drivers to be connected to a single user process. STREAMS does not provide a general multiplexing driver, but does provide the facilities for constructing them and for connecting multiplexed configurations of streams.
Network endpoint objects are sockets and the transport level interface (TLI). See mandatory access control for definitions of the MAC policies. Network endpoint objects are subject to the read-equal-write-equal policy.
Anything in the Trusted Solaris environment that a process attempts to access. The six major object types are file system objects, process objects, System V IPC objects, STREAMS objects, network endpoint objects, device objects, and X window objects.
An offset maximum is an attribute of an open file description representing the largest value that can be used as a file offset.
A process group in which the parent of every member in the group is either itself a member of the group, or is not a member of the process group's session.
A path name is a null-terminated character string starting with an optional slash (/), followed by zero or more directory names separated by slashes, optionally followed by a file name.
If a path name begins with a slash, the path search begins at the root directory. Otherwise, the search begins from the current working directory.
A slash by itself names the root directory.
Unless specifically stated otherwise, the null path name is treated as if it named a non-existent file.
Each process in the system is uniquely identified during its lifetime by a positive integer called a process ID. A process ID may not be reused by the system until the process lifetime, process group lifetime, and session lifetime ends for any process ID, process group ID, and session ID equal to that process ID. Within a process, there are threads with thread id's, called thread_t and LWPID_t. These threads are not visible to the outside process.
A new process is created by a currently active process (see fork(2)). The parent process ID of a process is the process ID of its creator.
Having appropriate privilege means having the capability to override some aspect of security policy. If a man page states that a system call needs to have or to assert "the appropriate privilege" to bypass DAC or MAC restrictions, see File Access Permissions for the override privilege that applies to the type of access being denied. A privilege is only granted by a site's security administrator after judging that the command itself or the person will use the privilege in a trustworthy manner. See File Privilege Sets and Process Privilege Sets.
This one-bit flag indicates that the process is in privilege debugging mode, an operational mode where any attempt by the process to use a privilege is logged. This flag can be viewed or cleared, but can be set only by a trusted path process. This flag is set by runpd(1M) when executing a command in privilege debugging mode, and then is inherited by the process. It works only if the _PRIVS_DEBUG kernel switch is also enabled (see secconf(2)).
Trusted Solaris flags that indicate security-related values that are copied from one process to another on fork(2) and cloned without changes on exec(2). They are: the Trusted Path Flag, the Privilege Debugging Flag, the Network Token Mapping Process Flag, the Label View Flag (External View or Internal View), the Label Translation Flags, the Diskless Boot Flag, the Cut and Paste Selection Agent Flag, the Trusted System Printing flag, and the Automount flag. See pattr(1), getpattr(2) , and setpattr(2). Each flag has its own protection policy. Any process may view or clear any process attributes flags except for the Label Translation flags, which are viewable and clearable by only a process with the trusted path attribute. Any process may set the Label View flags, but only processes with the trusted path attribute may set any of the other process attribute flags.
Each process in the system is a member of a process group that is identified by a process group ID. Any process that is not a process group leader may create a new process group and become its leader. Any process that is not a process group leader may join an existing process group that shares the same session as the process. A newly created process joins the process group of its parent.
A process group leader is a process whose process ID is the same as its process group ID.
Each active process is a member of a process group and is identified by a positive integer called the process group ID. This ID is the process ID of the group leader. This grouping permits the signaling of related processes (see kill(2)).
A process lifetime begins when the process is forked and ends after it exits, when its termination has been acknowledged by its parent process. See wait(2).
A process group lifetime begins when the process group is created by its process group leader, and ends when the lifetime of the last process in the group ends or when the last process in the group leaves the group.
Process and lightweight processes (independently scheduled threads of execution), which are subject to the write-up-read-down policy. See object for definitions of the MAC policies.
The privileges used by a process are stored in sets called the inheritable, permitted, effective, and saved sets. When a process
executes a program through the execve(2) system call, the permitted (P) and effective (E) privilege sets are reset equal to the same value, which is the intersection of the process' previously
existing inheritable (I) privileges and the program file's allowed (A) privileges intersected with the program file's forced (F) privileges: P=E=(I[process] union F[program] restricted by A[program]). The saved privilege set is set initially to the intersection of the existing inheritable
privilege set and the file's allowed privileges: S=(I[process] intersected by A), which allows the process to determine which privileges it had when the currently executing program was invoked. When a new program is invoked, the inheritable privilege set is initially set to be the same as the inheritable
privileges of the process that invoked the current program: I[new]=I[old]. Setting the inheritable privileges without reference to the forced or allowed privileges on an executing program allows privileges to be passed without change from a program that cannot use them to one that can.
For compatibility with the Solaris operating environment's super-user capability, if the effective UID is set by setuid(2) to be different from the original, the effective
set is copied to the saved set and the effective set is cleared: S=E; E=0. When the process changes its effective user ID back to the original, the saved privilege set is copied to the effective set, thus restoring its privileged state: E=S. In addition to automatic
changes in privilege sets as the result of execve() or setuid(), a process may manipulate its own privilege sets with the getppriv(2) and setppriv(2) system calls. For example, a process can use these calls to move permitted privileges into and out of its effective privilege set, for privilege bracketing. A process with the PRIV_SET_FPRIV
privilege in its effective set can use setfpriv(2) to set privileges on a file. See the Trusted Solaris Developer's Guide for more
details about how privileges may be manipulated within programs using system calls.
Security attributes received by processes from the Solaris operating environment are: the process ID (PID), the real, effective, and saved user ID, the real, effective, or saved group ID, the supplementary group IDs, the user audit ID, the audit session ID, the audit preselection mask, the terminal ID, and the umask (see Masks). Security attributes received by processes from the Trusted Solaris system are: the process clearance, the CMW label, the process attribute flags, and the permitted, effective, inheritable, and saved process privilege sets.
The processors in a system may be divided into subsets, known as processor sets. A process bound to one of these sets will run only on processors in that set, and the processors in the set will normally run only processes that have been bound to the set. Each active processor set is identified by a positive integer. See pset_create(2).
In a stream, the message queue in a module or driver containing messages moving upstream.
Each user allowed on the system is identified by a positive integer (0 to MAXUID) called a real user ID.
Each user is also a member of a group. The group is identified by a positive integer called the real group ID.
An active process has a real user ID and real group ID that are set to the real user ID and real group ID, respectively, of the user responsible for the creation of the process.
Each process has associated with it a concept of a root directory and a current working directory for the purpose of resolving path name searches. The root directory of a process need not be the root directory of the root file system.
Saved resource limits is an attribute of a process that provides some flexibility in the handling of unrepresentable resource limits, as described in the exec family of functions and setrlimit(2).
The saved user ID and saved group ID are the values of the effective user ID and effective group ID prior to an exec of a file whose set user or set group file mode bit has been set (see exec(2)).
An attribute used in enforcing the Trusted Solaris security policy. Various sets of security attributes, both from the Solaris operating environment and the Trusted Solaris operating environment, are assigned to processes, users, files, directories, file systems, hosts on the trusted network, allocatable devices, and other entities. See Process Security Attributes.
In the Trusted Solaris environment, the set of rules for DAC, MAC, and privilege interpretation that define how information may be accessed. At a customer site, the set of rules that define the sensitivity of the information being processed at that site and the measures that are used to protect the information from unauthorized access.
A semaphore identifier (semid) is a unique positive integer created by a semget(2) call. Each semid has a set of semaphores and a data structure associated with it. The data structure is referred to as semid_ds and contains the following members:
struct ipc_perm sem_perm; /* operation permission struct */$ struct sem *sem_base; /* ptr to first semaphore in set */$ ushort_t sem_nsems; /* number of sems in set */$ time_t sem_otime; /* last operation time */$ time_t sem_ctime; /* last change time */$ /* Times measured in secs since */$ /* 00:00:00 GMT, Jan. 1, 1970 */
The following are descriptions of the semid_ds structure members:
The sem_perm member is an ipc_perm structure that specifies the semaphore operation permission (see below). This structure includes the following members:
uid_t uid; /* user id */ gid_t gid; /* group id */ uid_t cuid; /* creator user id */ gid_t cgid; /* creator group id */ mode_t mode; /* r/a permission */ ulong_t seq; /* slot usage sequence number */ key_t key; /* key */
The sem_nsems member is equal to the number of semaphores in the set. Each semaphore in the set is referenced by a nonnegative integer referred to as a sem_num. sem_num values run sequentially from 0 to the value of sem_nsems minus 1.
The sem_otime member is the time of the last semop(2) operation.
The sem_ctime member is the time of the last semctl(2) operation that changed a member of the above structure.
A semaphore is a data structure called sem that contains the following members:
ushort_t semval; /* semaphore value */ pid_t sempid; /* pid of last operation */ ushort_t semncnt; /* # awaiting semval > cval */ ushort_t semzcnt; /* # awaiting semval = 0 */
The following are descriptions of the sem structure members:
The semval member is a non-negative integer that is the actual value of the semaphore.
The sempid member is equal to the process ID of the last process that performed a semaphore operation on this semaphore.
The semncnt member is a count of the number of processes that are currently suspended awaiting this semaphore's semval to become greater than its current value.
The semzcnt member is a count of the number of processes that are currently suspended awaiting this semaphore's semval to become 0.
In the semop(2) and semctl(2) function descriptions, the permission required for an operation is given as {token}, where token is the type of permission needed interpreted as follows:
00400 READ by user 00200 ALTER by user 00040 READ by group 00020 ALTER by group 00004 READ by others 00002 ALTER by others
Read and alter permissions on a semid are granted to a process if the read-equal-write-equal mandatory access control check is passed or if the process asserts the appropriate override privilege (either PRIV_IPC_MAC_READ
or PRIV_IPC_MAC_WRITE
), and if one of the following tests is true.
The effective user ID of the process matches sem_perm.cuid or sem_perm.uid in the data structure associated with semid and the appropriate bit of the "user" portion (0600) of sem_perm.mode is set.
The effective group ID of the process matches sem_perm.cgid or sem_perm.gid and the appropriate bit of the "group" portion (060) of sem_perm.mode is set.
The appropriate bit of the "other" portion (06) of sem_perm.mode is set.
The process has asserted the appropriate DAC privilege, either PRIV_FILE_DAC_READ
or PRIV_FILE_DAC_WRITE
.
Otherwise, the corresponding permissions are denied.
A sensitivity label defines the level of protection afforded to a labeled object or the level of access granted a labeled subject. Sensitivity labels are used in all mandatory access control (MAC) decisions by the Trusted Solaris environment. A sensitivity label consists of a hierarchical classification and a set of non-hierarchical compartments. This classification-and-compartments pair is known as the level of the sensitivity label.
A session is a group of processes identified by a common ID called a session ID, capable of establishing a connection with a controlling terminal. Any process that is not a process group leader may create a new session and process group, becoming the session leader of the session and process group leader of the process group. A newly created process joins the session of its creator.
Each session in the system is uniquely identified during its lifetime by a positive integer called a session ID, the process ID of its session leader.
A session leader is a process whose session ID is the same as its process and process group ID.
A session lifetime begins when the session is created by its session leader, and ends when the lifetime of the last process that is a member of the session ends, or when the last process that is a member in the session leaves the session.
A shared memory identifier (shmid) is a unique positive integer created by a semget(2) call. Each shmid has a segment of memory (referred to as a shared memory segment) and a data structure associated with it. (Note that these shared memory segments must be explicitly removed by the user after the last reference to them is removed.) The data structure is referred to as shmid_ds and contains the following members:
struct ipc_perm shm_perm; /* operation permission struct */ int shm_segsz; /* size of segment */ struct region *shm_reg; /* ptr to region structure */ char pad[4]; /* for swap compatibility */ pid_t shm_lpid; /* pid of last operation */ pid_t shm_cpid; /* creator pid */ ushort_t shm_nattch; /* number of current attaches */ ushort_t shm_cnattch; /* used only for shminfo */ time_t shm_atime; /* last attach time */ time_t shm_dtime; /* last detach time */ time_t shm_ctime; /* last change time */ /* Times measured in secs since */ /* 00:00:00 GMT, Jan. 1, 1970 */
The following are descriptions of the shmid_ds structure members:
The shm_perm member is an ipc_perm structure that specifies the shared memory operation permission (see below). This structure includes the following members:
uid_t cuid; /* creator user id */ gid_t cgid; /* creator group id */ uid_t uid; /* user id */ gid_t gid; /* group id */ mode_t mode; /* r/w permission */ ulong_t seq; /* slot usage sequence # */ key_t key; /* key */
The shm_segsz member specifies the size of the shared memory segment in bytes.
The shm_cpid member is the process ID of the process that created the shared memory identifier.
The shm_lpid member is the process ID of the last process that performed a shmat() or shmdt() operation (see shmop(2)).
The shm_nattch member is the number of processes that currently have this segment attached.
The shm_atime member is the time of the last shmat() operation (see shmop(2)).
The shm_dtime member is the time of the last shmdt() operation (see shmop(2)).
The shm_ctime member is the time of the last shmctl(2) operation that changed one of the members of the above structure.
In the shmctl(2), shmat(), and shmdt() (see shmop(2)) function descriptions, the permission required for an operation is given as {token}, where token is the type of permission needed interpreted as follows:
00400 READ by user 00200 WRITE by user 00040 READ by group 00020 WRITE by group 00004 READ by others 00002 WRITE by others
Read and write permissions for a shmid are granted to a process if the read-equal-write-equal mandatory access control check is passed or if the process asserts the appropriate override privilege (either PRIV_IPC_MAC_READ
or PRIV_IPC_MAC_WRITE
), and if one of the following tests is true:
The effective user ID of the process is super-user.
The effective user ID of the process matches shm_perm.cuid or shm_perm.uid in the data structure associated with shmid and the appropriate bit of the "user" portion (0600) of shm_perm.mode is set.
The effective group ID of the process matches shm_perm.cgid or shm_perm.gid and the appropriate bit of the "group" portion (060) of shm_perm.mode is set.
The appropriate bit of the "other" portion (06) of shm_perm.mode is set.
The process has asserted the appropriate DAC privilege, either PRIV_FILE_DAC_READ
or PRIV_FILE_DAC_WRITE
.
Otherwise, the corresponding permissions are denied.
A directory within an MLD containing only files at a single sensitivity label. The SLD directory name is derived from the SL of the process that created it. For example, the name of an SLD in /tmp would be in the form /tmp/.SLD.<sensitivity_label_of_creating_process>/. All subsequent references to the file in the /tmpdirectory would be made transparently as /tmp/file. Because pathname translation is transparent, the process would not need to explicitly reference the SLD directory, unless it chose to do so using the MLD adornment and the name of the SLD .
The process with ID 0 and the process with ID 1 are special processes referred to as proc0 and proc1; see kill(2). proc0 is the process scheduler. proc1 is the initialization process (init); proc1 is the ancestor of every other process in the system and is used to control the process structure.
A set of kernel mechanisms that support the development of network services and data communication drivers. It defines interface standards for character input/output within the kernel and between the kernel and user level processes. The STREAMS mechanism is composed of utility routines, kernel facilities and a set of data structures.
A stream is a full-duplex data path within the kernel between a user process and driver routines. The primary components are a stream head, a driver, and zero or more modules between the stream head and driver. A stream is analogous to a shell pipeline, except that data flow and processing are bidirectional.
In a stream, the stream head is the end of the stream that provides the interface between the stream and a user process. The principal functions of the stream head are processing STREAMS-related system calls and passing data and information between a user process and the stream.
When any type of label (sensitivity label or clearance) has a security level greater than the security level of another label to which it is being compared, the first label strictly dominates the second label. Strict dominance is dominance without equality, which occurs either when the classification of the first label is higher than that of the second label and the first label contains all the second label's compartments, or when the classifications of both labels are the same while the first label contains all the compartments in the second label plus one or more additional compartments.
The set of all valid (well-formed) labels created according to the rules defined by each site's security administrator in the label_encodings(4) file, plus the two administrative labels that are used in every Trusted Solaris environment, ADMIN_LOW
and ADMIN_HIGH
.
A process is recognized as a superuser process and is granted special privileges, such as immunity from file permissions, if its effective user ID is 0. In the Trusted Solaris environment, superuser is replaced by administrative roles that share responsibility for the environment.
Also called the Trusted Path Attribute, this one-bit flag indicates that the process is executing in the trusted path.
In a stream, the direction from driver to stream head.
In a stream, the message queue in a module or driver containing messages moving downstream.
X window objects are the windows in the common desktop environment (which is based on the X Window system). See mandatory access control for definitions of the MAC policies. Window objects are generally subject to the read-equal-write-equal policy. See the X library man pages (in /usr/openwin/man/man3) for exceptions.
NAME | SYNOPSIS | DESCRIPTION | ERRORS | DEFINITIONS