Chapter 5. Administering Access Control

Access control under Trusted IRIX/CMW has been described in general earlier in this guide. This chapter contains a detailed description of the mandatory and discretionary access control mechanisms. The Mandatory Access Control mechanism is the system of labels and clearances that enforce Mandatory Sensitivity and Mandatory Integrity of system objects. The Discretionary Access Control mechanisms are the standard system of file permissions, and the use of Access Control Lists on files and directories.

Sections in this chapter include:

Mandatory Access Control

Mandatory Access Control (MAC) is the most visible feature of CMW security. Under MAC, the system associates a label with each process, user, file, or device known to the system. Based on the relationship between the labels of two or more of the items, Trusted IRIX/CMW makes access control decisions.

Within MAC, two separate mechanisms control user access to files and programs. One is Mandatory Sensitivity (MSEN) and the other is Mandatory Integrity (MINT) . MSEN is simply the level of protection that a file or object needs, and the corresponding clearance of a user to view or use that file or program. MINT is the indication of how much trust the system has that the file or program is secure or valid, not corrupted or suspect. MINT declares the integrity of the file or program. For example, if an instruction to transfer a large amount of money is sent to the computer, the user wants to know that the message was trusted to be valid, and not a security breach being exploited. MINT assures that users with access to protected data have only trusted tools of high integrity with which to work.

Each label for a system subject (such as a user or process) or system object (such as a file or hardware resource) contains several components. These components are the sensitivity level, integrity grade, and possibly a number of sensitivity categories and integrity divisions. Sensitivity categories divide information into working sets. Information in one category is presumably unrelated to information in any other category. Any subject or object may be in multiple categories or have no associated categories. Similarly, integrity divisions classify different types of information based on decisions to trust the integrity of the information. The sensitivity level of a user determines what level of sensitive information he or she is allowed to use. Conversely, the integrity grade determines how trusted the information must be in order for the user to see it. The higher the integrity requirement, the more trusted the information must be.

For subjects, which are active entities such as users and processes, the sensitivity level, sensitivity categories, integrity grade, and integrity divisions together are called a clearance. Because subjects usually access and modify objects, subjects require clearance to perform those tasks. Objects, on the other hand, have classifications of sensitivity, integrity, divisions, and categories. The clearance of a subject must be at least equal to the classification of an object for MAC to allow the subject access to the object.

When a user logs in, the shell process created by the login program inherits the label that the user entered during the login process. The maximum and minimum clearances of a user are stored by the system in the /etc/clearance file. A user can log in at any clearance up to his or her maximum and down to the minimum. The login shell and any subsequently created processes inherit the login clearance as their label.

MSEN categories and MINT divisions within a label define the nature of the subject or object. For example, a user with the highest sensitivity in research and development does not necessarily have a need to see personnel or accounting information. Therefore, MAC allows you to create categories of information. A high clearance in one category does not allow access to information in other categories.

Each object can be defined in the label as belonging to a number of categories, or to no categories. Each user has a number of categories or no categories in their label. Each new process inherits the label, including all categories of the invoking user. Also, you can define MINT divisions to create a set of tools of known high integrity and limit their use to certain users. A user must have the same or a subset of the MINT divisions of an object in his or her label in order to use the object. All other requirements of sensitivity and general integrity still apply.

The concept of label domination and equivalence is central to MAC. If a subject's clearance is greater than an object's classification and the integrity of the object is good enough for the subject, the subject is said to dominate the object. If the clearance and classification are equal, the labels are said to be equal. A subject must be at least equal to or must dominate an object in order to access it. For more information on label domination and equivalence, see the dominance(5) man page.

When you add categories to MAC, you affect the usual order of dominance of your security classifications. In order to dominate , a label must have the same or higher sensitivity and a set of approved categories that are the same as or a superset of the categories of the object, and the integrity requirement for the user must be met by the file. Also, the integrity divisions of the user must be the same or a subset of the integrity divisions of the object. Table 5-1 lists possible label relationships using the default labels supplied with your system. In the table, the levels of sensitivity are unclassified, proprietary, and company sensitive. The categories are green, gray, and gold. The integrity grades are good, choice, and prime. The integrity divisions are cake, cookie, and cracker. The labels are written in the form of sensitivity level-categories, integrity grade-divisions.

Table 5-1. Sample Label Relationships

Subject Label

Object Label






Clearance dominated; integrity dominated




Integrity of the object not good enough

proprietary, green/ good

unclassified,green/ good


Clearance dominates; categories equal; integrity equal

prime, cake

prime, cake, cookie,


Clearances identical;
integrity divisions

proprietary/green, prime

company sensitive, green/ prime


Object classification higher than subject clearance

proprietary, green/prime

proprietary, green, gray/prime,cake, cookie


Categories not equal or dominated

proprietary, green, gray/prime, cake, cookie

proprietary, green, gray/prime, cake, cookie


Categories equal; integrity equal

proprietary, green, gray, gold/choice

proprietary, green, gray/prime


Categories dominated; integrity dominated

Types of Labels

The following sections describe the various types of security labels used under the Trusted IRIX/CMW system.

Trusted IRIX/CMW Default Labels

Your Trusted IRIX/CMW operating system comes with a small set of predefined labels. Do not delete these labels for any reason, because all but one of them are administrative. The defined labels are shown in Table 5-2.

Table 5-2. Trusted IRIX/CMW Default Labels





for TCB changes only



for editing system data files



for creating new user files



for /dev/null



alias for msenlow/mintbiba


Additionally, various default MSEN levels and MINT grades are defined in the /etc/mac file. You may use these hierarchical components and the default categories and divisions to make more labels or you can define your own.

Equal (Wildcard) Labels

Equal (or wildcard) labels are a special type of label reserved for use by the system and by the system administrator. An equal label is sometimes referred to as a wildcard label, because it always compares as equal in any label comparison. For example, a user running at userlow perceives the equal label as also being at userlow, while a user running at userhigh perceives that label as userhigh.

Administrative Labels

The administrative labels are dblow and dbadmin. These labels are not considered directly comparable with ordinary user labels. They are arbitrary definitions of the lowest and highest possible sensitivities on the system. These labels are generally reserved for system objects and administrative accounts. dblow files are considered to be part of the TCB, and they are of low sensitivity and the highest integrity. Thus, they are dominated by all labels and accessible to all users. For example, the /bin/cat program is available to all labels. dbadmin files are of the highest integrity and also of the highest sensitivity found on the system. These files contain data that must not be divulged or compromised. For example, the /etc/shadow file, which contains each user's encrypted password, is not available for general perusal.

No user should be able to log in at either of these labels, although exceptions are made for user accounts belonging to system administrators.

User (CC) Labels

Ordinary user labels (also called CC label type s, after the Common Criteria international standard ISO IS 15408) are those that the user sees in day-to-day work. Trusted IRIX/CMW is shipped with only one user-level label configured, userlow. As your user label library grows, remember to keep the hierarchy of labels clear, consistent, and easy to understand.

User labels always dominate, but are never equal to dblow. No user label can dominate dbadmin.

Batch processing jobs (such as those submitted through at, batch, and cron) may be submitted at any label for which the user is cleared, and they are run with that label. Entries in crontab files are also allowed at any label for which the user is cleared, with a separate file being maintained at each label requested.

Changing User Default Labels

If the user's default label is changed while there are scheduled tasks pending, the tasks will be run at the new default label, not at the label at which they were submitted.

Before changing a default label, the system administrator must verify that either the user has no outstanding requests or that the requests are appropriate at the user's new default label. The system administrator can find the background task request information in the /var/spool/cron/atjobs and /var/spool/cron/crontab files, as described in the cron(1M) man page.

Complete information on at, batch, and cron is available in their respective man pages, and in the guide titled IRIX Admin: System Configuration and Operation.

Multilevel Labels

It is possible to hold a multilevel label. You can use the following commands to change your current label to multilevel:

newlabel -m 
su username -m

The advantage of multilevel labels is their use with multilevel directories. A multilevel directory (sometimes called a moldy directory) places files of different labels into multiple hidden subdirectories. Each subdirectory bears the label of the files in that subdirectory. Thus, process A with label userhigh sees a different listing of the contents of the mld from process B with label userlow. However, neither process sees the subdirectory structure. Each process sees only files with the same label as the process in the mld. Once your label is multilevel, you can see the multilevel directory structure, but the rules of dominance are still in effect. You cannot see the contents of a subdirectory whose label you do not dominate, though you can see that the subdirectory exists. To create a multilevel directory, use the mkdir command and then use the chlabel command with the -m flag and the name of the directory; the directory becomes multilevel.

Three types of multilevel labels are available: msenmldhigh, msenmld, and msenmldlow. msenmldhigh is a multilevel msenhigh clearance to give MSEN (though not necessarily MINT) dominance over all files on the system. msenmld labels at other MSEN levels are subject to the rules of dominance. msenmldlow is a multilevel dblow label for working with the TOE. You can log in with a multilevel label of one of these types, or you can log in at msenhigh/mintequal, dblow, or any label and use the newlabel -m command option to make your label multilevel.

Working With Labels

The following sections detail how to examine and manipulate labels on a Trusted IRIX/CMW system:

  • Checking labels

  • Changing object labels

  • Changing process labels

  • Creating new label names

  • Deleting a label

Checking Labels

Frequently, you will find it necessary to check the label of a fil e or directory, or perhaps the labels of all the files in a moldy directory. For this purpose, Trusted IRIX/CMW supports the -M flag to the ls command. The ls -M command lists files according to the usual behavior of ls, except that the human-readable names of the labels attached to the files or directories are displayed as well.

The id command displays the calling process ID number and name. It also displays the group ID and name. If the real and effective IDs do not match, both are printed. When invoked with the -M option, id reports the MAC label at which the invoking process is running.

Using attrinit to Clean Up Label Corruption

If you believe you have experienced corruption of some labels, you can use the attrinit command to restore your system labels. See the attrinit(1) man page for more information on attrinit command.

The /etc/irix.mac file is used with the attrinit command as follows:

  1. Log in as root and change directories to the / directory.

  2. Enter this command:

    attrinit -script=etc/irix.mac 

It takes several minutes while your labels are restored.

Changing Object Labels

You can change the label of an object with the chlabel command. Be aware that you must have access to the object before giving the command. You cannot use chlabel to change the label of an inaccessible object. The new label cannot be less sensitive or of higher integrity than the old label. Additionally, the current label of the object must be equal to that of the process attempting the change. The -m flag to chlabel changes the label of a directory to multilevel.

The system administrator may set a file or directory to any label; you must have sufficient privilege. If a user accidentally changes the label on a file and can no longer access the file, the system administrator must downgrade the file for the user. The system administrator is also the only user who may set an equal label. For complete information about the chlabel command, consult the chlabel(1) man page.

Changing Process Labels

Sometimes you will find it necessary to run a program or other process at a labe l different from your current login label. For example, the process may require a lower integrity requirement or a higher clearance. The newlabel command allows you to run a process at a different label. The processes you may run include opening a new shell window and using the command su -M.

To prevent inappropriate transfers or disclosures of information, all open file descriptors associated with your login shell process are closed before the new process is invoked. This assures that information at a higher classification will not be used as any input to the new process, which may be running at a lower clearance. The default new process is your default command shell, as specified in your environment.

Remember that you can execute newlabel only with a specified clearance up to the maximum allowed for your login account. For complete information about newlabel, consult the newlabel(1) man page.

You may also use the su command with the -M option to execute a command at a higher label, provided you are cleared for that label, or have the password of an account that is cleared for that label. See the su(1M) man page for complete information.

Creating New Label Names

From time to time, it may become necessary to create new label names on your system, to adapt to changing usage and new projects. You also must create your starting set of labels when you install your system. The /etc/mac file defines the sensitivity clearances and categories and the integrity grades and divisions. This file contains a “starter set” of predefined labels and label components for you to use. As you add your own labels to this file, remember that in no instance should you delete any of the distributed label components. Trusted IRIX/CMW depends on many of these defined labels and components. Also, remember as you edit that everything you put in the file is case-sensitive. That is to say, the system differentiates between uppercase and lowercase letters in the names of the items. Also, each new label name must be unique. For example, you cannot use the name “good” for both a sensitivity level and an integrity grade.

To add new label names, edit the /etc/mac file at dblow. The format is


The following table is a short summary of the types and values in the /etc/mac file:

Table 5-3. Types and Values in the /etc/mac File





numeric value

The gradenames type defines integrity grades. The higher the numeric value, the greater the integrity of the grade. You must decide where you wish to position the new grade in your integrity hierarchy by examining the numeric values of the existing integrity grades and assigning the new number at the appropriate level.


numeric value

The divisionnames type defines integrity divisions. For divisions, the numeric value of the new definition is arbitrary and for identification only. You need only make certain that the new number is not already in use. The values 0-99 are reserved for system use.


numeric value

The levelnames type defines sensitivity levels. The higher the numeric value, the greater the sensitivity of the level. You must decide where you wish to position the new level in your sensitivity hierarchy by examining the numeric values of the existing sensitivity levels and assigning the new number at the appropriate level.


numeric value

The categorynames type defines sensitivity categories. For categories, the numeric value of the new definition is arbitrary and for identification only. You need only make certain that the new number is not already in use.

Note that if you are using CIPSO Type 1 as your networking environment, only categories 1-239 can be transmitted.

If you are using CIPSO Type 2 as your networking environment, a maximum of 15 categories per label can be transmitted.

Deleting a Label

Never delete a label name once it has been used on your system. Change all files that have the label to another label and remove the label from the ranges of all your users. Then, comment out the entry in the /etc/mac file by placing a pound sign (#) at the beginning of the definition line. In this way, no one can use the label, just as if it had been removed, but a record remains that the label existed. This is necessary to prevent accidental reuse of the label for another purpose. If the name of a sensitivity level, category, integrity grade, or division is reused, a declassification of information could result. For example, if a sensitive file is left unchanged after a label is removed, and the label name is reused, that sensitive file is available to users not cleared for the information.

Discretionary Access Control

Discretionary Access Control (DAC) is the name of the standard UNIX system of access permissions that allow the user to control access to files, directories, and other system resources.The added feature of Access Control Lists (ACLs) is implemented in IRIX. The owner of any file or other system object can control access to that object, even by those with equal or dominating clearances, by setting the DAC permissions. Further, the user may set an ACL for any file or directory. ACLs are discussed in the section titled “Access Control Lists”.

The significant difference between MAC and DAC is that DAC allows untrusted users to control access to their own files and change that access at will. Thus, DAC fills an otherwise unmet need for system security at the personal level. Every file on the system is subject to both MAC and DAC. You must meet both MAC and DAC requirements to access a file.

Trusted IRIX/CMW File Permissions

Trusted IRIX/CMW divides permissions into three categories, and users into three relationships. The three categories of permissions are read, write, and execute. They are denoted as “r” for read, “w” for write, and “x” for execute.The three relationships are the owner of the file, the owner's user group, and every other user. If you get a long listing of a directory, you see that the permissions field for each file in the directory looks something like this:


Note that the line of permissions has the string rwx repeated three times. The first instance of rwx applies to the file owner, the next instance applies to the group members, and the third applies to all other users on the system. The example above shows full permissions. A more restricted permission set might look like this:


To get a long listing of file permissions , enter this command at your system prompt in any directory:

ls -l 

Along with the permission information, the ls -l command lists the owners of the files, the size of the files, and the date they were last modified.

Read permission allows you to look at the contents of a file. Write permission allows you to make changes to or remove a file. Execute permission allows you to run the file as a command from your shell prompt.

Each character is separately significant in the permissions listing. Starting at the left, the first character is a dash. A dash in any other position means that no permission is granted and the actions associated with that permission are denied. However, in the leftmost place, the contents of that space describe whether the file is a file or a directory. If it is a directory, a “d” appears in that space. Other characters in this place indicate that the file is a pipe, a block or character special device file, or other type of file. See the ls(1) man page.

Directory Permissions

Directories use the same permissions as files, but their meanings are slightly different. For example, read permission on a directory means that you can use the ls command to look at the contents of that directory. Write permission allows you to add, change, or remove files in that directory. (However, even though you may have write permission in that directory, you must also have write permission on the individual files to change or remove them, unless you own the directory.) Finally, execute permission on a directory allows you to use the cd command to change directories into that directory.

File Permissions

The first set of three places after the leftmost place in the permissions field describe the permissions for the owner of the file . Here is an example of a long listing for a file:

-rwx------ 1 owner grp 6680 Apr 24 16:26 shell.script 

The characters rwx indicate that the owner of the file, owner, has read, write, and execute permission on this file. The second set of three spaces describe permissions for the owner's group. In this case, the group is grp. Suppose permissions for this file were slightly different, like this:

-rwxr-x--- 1 owner grp 6680 Apr 24 16:26 shell.script 

Any member of the group grp could read or execute the file, but not change it or remove it. All members of group grp can share a pool of files that are individually owned. Through careful use of group read and write permissions, you can create a set of files that are owned by one person, but any group member can work on them.

The third set of spaces provides for all other users on the system and is called the public permissions. A file that is set to be readable by any user on the system is called publicly readable. Remember that even if DAC makes a file publicly readable, a user must still have appropriate MAC clearance to see the file.

Here is a long listing of a sample Projects directory:

total 410 
drw------- 1 owner grp 48879 Mar 29 18:10 critical 
-rw-r--r-- 1 owner grp  1063 Mar 29 18:10 meeting.notes 
-rw-rw-rw- 1 owner grp  2780 Mar 29 18:10 
-rwxrwxrwx 1 owner grp  8169 Jun 7  13:41 new.items 
-rw-rw-rw- 1 owner grp  4989 Mar 29 18:10 response 
-rw------- 1 owner grp 23885 Mar 29 18:10 project1 
-rw-r----- 1 owner grp  3378 Jun 7  13:42 saved_mail 
-rw-r--r-- 1 owner grp  2570 Mar 29 18:10 schedules 
-rwxrwxr-x 1 owner grp  6680 Apr 24 16:26 shell.script 

The files in this directory have varying permissions. Some are restricted to the owner, some can be read only by members of the owner's group, and some can be read, changed, or removed by anybody. The shell script is executable by any user.

Changing Permissions

You change the permissions on a file by using the chmod command. You can use chmod only to change files that you own. Generally, you use this command to protect files you want to keep secret or private, to protect private directories, and to grant permissions to files that need to be used by others. The command to restrict access to a file or directory to yourself only is as follows:

chmod 600 filename 
chmod 700 dirname 

Other permissions may be added by using the chmod command with the letter associated with the permission. For example, the command to add general write permission to a file is as follows:

chmod +w filename 

For more examples, see the chmod(1) man page.

Setting Permissions With umask

You can decide what default permissions your files have by placing the umask command in your .cshrc, .profile, or .login file. There is a default umask setting for the entire system in the /etc/profile and /etc/cshrc files. By changing the setting of your umask, you can alter the default permissions on your files and directories to any available DAC permission. See the umask(1) man page for more information.

A drawback to the umask command is that it makes every file you create receive the same permissions. For most purposes, you want the files you create to be accessible by the members of your group. For example, if an individual is suddenly called away and another person must take over that person's portion of a project, the source files must be accessible by the new user. However, you might want the personal files you keep in your home directory to be private, and if you set your umask to allow group read and write access, any member of the group can access your personal files. But mechanisms are available to prevent this access. For example, you can create a directory of private files and alter the permissions on that directory with the chmod command to restrict all but your own access. Then no other user would be allowed into the directory.

You can also use the Trusted IRIX/CMW utilities to change all the files in your home directory to your chosen permission automatically at your convenience. You can set up your account so that this action happens to any files or directories you indicate every time you log out. For example, say you have three directories, called personal, letters, and budget. You can set up a .logout file in your home directory with commands to be executed each time you log out from the system. The following commands, placed in the .logout file, will prevent access to the three example directories for anyone but you:

chmod 700 budget personal letters 
chmod 600 budget/* personal/* letters/* 

The umask command is an important part of DAC. It allows you to maintain security and still allow convenient access to your files. To set your account up to allow group read and write access and no other access, place this line in your .cshrc or .profile file:

umask 007 

This makes every file you create have the following permissions:


With your umask set to 007, directories that you create have the following permissions:


In plainer terms, you and your group will have full use of the file or directory. No other user will have access to your files.

Access Control Lists

An Access Control List (ACL) works in the same way as standard file permissions, but it allows you to have a finer level of control over who may access the file or directory than standard permissions allow. ACLs allow you to specify file permissions on a user-by-user basis.

Every system file or directory has an ACL that governs its discretionary access. This ACL is referred to as the access ACL for the file or directory. In addition, a directory may have an associated ACL that governs the initial access for files and to subdirectories created within that directory; this ACL is referred to as a default ACL. A user who wishes to gain access to the files in a directory must be allowed by the access ACL and by MAC to gain access successfully.

Hereafter in this section, directories are treated as files, and where the term file is used, consider that it also applies to directories.

An ACL is stored in the same way that standard file permissions are stored; as an attribute of the file or directory. To view the ACL of a file, use the ls -D command, as shown in this example:

ls -D /usr/people/ernie/testfile 

This produces output similar to this:

testfile [u::rwx,g::rwx,o::rx,u:332:r--,u:ernie:rw,m::xrw]

This example shows full permissions for the owner with the first entry on the line, sets read permission for user ID 332 with the second entry, and sets read/write permission for the user account ernie. The specific format of an ACL entry is discussed in the section titled “Text Form for ACLs”.

To set or change an ACL, use the chacl command:

chacl acl_entry[,acl_entry]...pathname...

An ACL consists of a set of ACL entries separated by commas. An ACL entry specifies the access permissions on the associated file for an individual user or a group of users. The order of internal storage of entries within an ACL does not affect the order of evaluation. To read an ACL from an object, a process must have read access to the file. To create or change an ACL, the process must own the file.

ACLs have long and short text forms. The long text form is defined first in order to give a complete specification with no exceptions. The short text form is defined afterwards because it is specified relative to the long text form.

Text Form for ACLs

The text form for ACLs is used for either input or output of ACLs and is set up as follows:


Although it is acceptable to place more than one entry on a physical line in a file, placing only one entry per line improves readability.

Each entry contains one ACL statement with three required colon-separated fields and an optional comment:

entry tag type:entry qualifier:discretionary access permissions#comment 

Comments may be included with any entry. If a comment starts at the beginning of a line, then the entire line is interpreted as a comment. The first field must always contain the ACL entry tag type.

One of the following ACL entry tag type keywords must appear in the first field:


Access granted to either the file owner or to a specified user account.


Access granted to either the file-owning user group or to a specified user group.


Access granted to any process that does not match any user, group, or implementation-defined ACL entries.


Maximum access that can be granted by any ACL entry except the user entry for the file owner and the other entry.

The second field contains the ACL entry qualifier (referred to in the remainder of this section as simply qualifier). The following qualifiers are defined by default:


User account name or a user ID number.


User group name or a group ID number.


No uid or gid information is to be applied to the ACL entry. The entry applies to the file owner only. An empty qualifier is represented by an empty string or by white space.

The third field contains the discretionary access permissions that are to apply to the user or group specified in the first field. The discretionary access permissions field may contain one each of the following characters in this order:


Read access


Write access


Execute access

This would appear as rwx. Any or all of these may be replaced by a dash (), which is the no-access character.

A user entry with an empty qualifier specifies the access granted to the file owner. A user entry with a uid qualifier specifies the access permissions granted to the user name matching the uid value. If the uid value does not match a user name, then the ACL entry specifies the access permissions granted to the user ID matching the numeric uid value.

A group entry with an empty qualifier specifies the access granted to the default user group of the file owner. A group entry with a gid qualifier specifies the access permissions granted to the group name matching the gid value. If the gid value does not match a group name, then the ACL entry specifies the access permissions granted to the group ID matching the gid value. The umask and other entries contain an empty qualifier. A pound sign (#) starts a comment on an ACL entry. A comment may start at the beginning of a line, or after the required fields and after any custom-defined, colon-separated fields. The end of the line denotes the end of the comment.

White space is permitted (but not required) in the entries as follows:

  • At the start of the line

  • Immediately before and after a colon (:) separator

  • Immediately before the first pound sign (#) comment character

  • At any point after the first pound sign (#) comment character

Comments have no effect on the discretionary access check of the object with which they are associated.

Here is an example of a correct long text form ACL for a file:


The above example sets full permissions for the owner with the first entry on the line, sets read permission for user ID 332 with the second entry, and sets read/write permission for the user account ernie.

Here are some examples with comments:

group:10:rw-# User Group 10 has read/write access
other::---# No one else has any permission
mask::rw-# The maximum permission except for the owner is read/write

The ACL entry may be shortened by using the following abbreviations for the entry tag types:









For example, a shortened ACL entry could look very similar to the following:

u::rwx # The file owner has complete access
u:332:r-- # User Acct 332 has read access only
g:10:rw- # User Group 10 has read/write access
u:653:r-- # User Acct 653 (who is in group 10) has read access only
o::--- # No one else has any permission
m::rw- # The maximum permission except for the owner is read/write

Using ls -D and chacl

You can use the output from the ls -D command as the input to chacl (via a copy and paste action). This is convenient for situations where you wish to duplicate a complex custom ACL onto a new file in a directory that does not use the complex ACL as the default.

Consider the command:

ls -dD testdir

It produces the following output:

testdir [u::rwx,g::r-x,o::--x/u::rwx,g::r-x,o::---]

Capability Assignment

The capability-based privilege mechanism, described in Chapter 2, assigns capabilities to the system administrator (root) and to the auditor (auditor) as requested at login based on the contents of the user capability database file (/etc/capability). These capabilities determine the amount of privilege granted by the capability-based privilege mechanism to the system administrator and auditor. (For more information on the format of the user capability database, see the capability(4) man page.)

Note: In the augmented superuser privilege environment, the system administrator has unlimited privilege regardless of the contents of the user capability database, though the auditor is still constrained.

It is inappropriate to grant capabilities to users other than root and auditor. Software used by ordinary users is automatically granted the capabilities it needs based on file capabilities; a user with capabilities beyond this is some form of administrator. The IRIX administrative model does not support administration by users other than root and auditor, so assignment of user capabilities to other users is not supported by IRIX or Trusted IRIX/CMW systems.

In addition to user capabilities, the IRIX system employs capabilities assigned to files. For details on how these work, see the capabilities(4) man page. File capabilities can be viewed by using the ls -P command and changed by using the chcap command.

The capability sets assigned to files in the IRIX system and related products are designed to establish appropriate privilege for correct system operation. Changing the file capabilities on an IRIX command or SGI product may degrade system functionality or compromise security. You must take care when assigning or change file capabilities to avoid this risk.

If you believe that the file capabilities on your system have become corrupt, you can use the attrinit command to restore file capabilities to their original settings (see the attrinit(1) man page). The /etc/irix.cap file is used with the attrinit command.

Follow these steps:

  1. Log in as root.

  2. Change your directory to the / directory.

  3. Enter the following command:

    attrinit -script /etc/irix.cap -verify install

Your capability integrity will be restored. The process may take a few minutes.

Like set-user-ID (SUID) and set-group-ID (SGID) programs, programs assigned capabilities (set-capabilities (SCAP) programs) are handled differently. A user cannot use the process activity reporter par system utility program on a SCAP process or trace a SCAP process unless the user has the CAP_PROC_MGT capability. See the par(1) and exec(2) manpage for more details

Similarly, certain environments variables are not respected when dealing with SCAP programs. These includes _RLD*_LIST and LD_LIBRARY*_PATH environment variables of the runtime linker rld command, the IFL_DATABASE environment variable of the Image Format Library ifl command (see rld(1) and ifl(1)) and the NLSPATH environment variable of the open/close a message catalogue catopen routine that allows user control of message formatting (see catopen(3C)).