HP-UX Reference (11i v2 07/12) - 4 File Formats (vol 8)

c
compartments(4) compartments(4)
This access control is inherited, so any file or directory under this file_object can be
read or listed.
write Controls write access to the file_object. If the file_object is a file,
write allows
processes in this compartment to open the file for writing. This permission has no
direct effect if file_object represents a directory. There is still an indirect effect as the
access control is inherited, so any file under this file_object can be written to.
create Controls create access to the file_object. The rule has an effect only if file_object is a
directory. This access control is inherited, so processes in this compartment can
create file objects anywhere under the specified directory.
unlink Controls delete access to the file_object. The rule has an effect only if file_object is a
directory. This access control is inherited, so processes in this compartment can
delete file objects anywhere under the specified directory.
file_object Fully-qualified name of a file or directory. This name is restricted in the following
ways:
• The total length of the name of the file_object cannot exceed
MAXPATHLEN bytes.
• Each component in the file_object name cannot exceed
MAXNAMELEN bytes.
• There can be no more than 10 components in the file_object name. Because one
component must be the name of the file or directory, there can be no more than
nine preceding components. For example, the path /a/b/c/d has four com-
ponents.
• The file_object is literal; that is, wild card characters such as asterisk (*
) cannot be
specified.
• The file_object has no special or space characters. All characters except
a-z,
A-Z,
0-9, slash (/), dot (.), dash (-), underscore (
_), and colon (:), must be entered
using the notation
%xx where xx corresponds to the hexadecimal representation
of the character. See ascii(5) for translating an ASCII character to its hexadecimal
equivalent.
File system rules are based on the path name. One can specify rules for an object that do not yet exist. In
such a case, the rule becomes operational when an object with that name is created. If a file has two or
more names (i.e., multiple hardlinks), and the two names have different rules for any compartment,
vhardlinks command generates warnings. In order to successfully create a hard link (e.g., using
link(2)), the new name and the old name must have the same rules. As with discretionary access con-
trol (DAC) methods, when a symbolic link is accessed, the rule on the resolved file--not the link itself--is
applied.
When a directory, say, /orig, is looback mounted on say, /lofs, any access to objects under these direc-
tories using either name result in application of the rule corresponding to the path beginning from
/orig
but not from /lofs.
IPC Rules
IPC rules appear within a compartment definition and govern how processes in this compartment can
access another compartment’s IPC mechanisms and how processes in other compartments may access this
compartment’s IPC mechanisms. Since the default is to deny access, rules of this type are only for allowing
access. Rules of this type can be either subject-centric or object-centric. Two formats are available for IPC
rules.
The first form of IPC rules controls process communication and uses the following format:
(grant|access)(pty|fifo|uxsock|ipc) compartment_name
where the values are defined as follows:
grant Allows processes in the compartment compartment_name to access the specified IPC
mechanism in this compartment. This keyword specifies an object-centric rule.
access Allows processes in this compartment to access the specified IPC mechanism in com-
partment compartment_name. This keyword specifies a subject-centric rule.
pty Applies to terminals (ptys and ttys) that are used to communicate between processes.
Note that these rules are applied in addition to any file system rules that control the
54 Hewlett-Packard Company − 2 − HP-UX 11i Version 2: December 2007 Update