Chapter 4. IRIX System Security

This chapter deals with security of local systems. It includes the following sections:

About System Security

Once you have initially established the security of a system, you can expand your secure area to include the network. But until you have local security, there is no point in trying to establish security over a larger area.

In addition, security is never finally established. Security is a dynamic process, requiring you to understand many issues, keep up to date on them, and continually monitor your systems with the many tools available. This book endeavors to provide the information you need to establish a security policy and begin its implementation.

It is one thing to secure an isolated IRIX system, another to secure a local area network, and still another to secure a site that is connected to external wide area networks such as the Internet. This chapter deals primarily with taking steps to secure an isolated system, but many of these same steps must also be taken before undertaking the more ambitious job of securing a network.

Chapter 5, “Network Security” discusses network security issues, which become important after the issues discussed in this chapter have been addressed to your satisfaction. If your systems are not connecting to the Internet but only to a trusted local area network, you should still read the first part of Chapter 5, “Network Security”, “ Local Area Network Access” in Chapter 5.

Note: The System Manager GUI provides Security and Access Control tasks that you can use to help manage security on your system. Refer to the Personal System Administration Guide for more information. The discussion in this chapter is based on the command-line and file interface to many of the same functions controlled with the GUI.

Standard Security Features

IRIX has several features that allow you to achieve a generally acceptable level of security without adding any new software. A great strength of the IRIX system is the ease with which users can share files and data. However, some of the security guidelines presented in this chapter are at odds with convenient system access. It is up to you, the system administrator, to balance the needs and concerns of the user community.

Standard security features of IRIX are:

  • File ownership split into three classes—owner, group, and other—permits the owner of files to specify who is allowed access to the files.

  • Permissions split into three categories—read, write, and execute—permits the owner of files to specify the degree of access users may have to the files.

  • Individual user accounts, protected by individual, encrypted passwords.

  • Tools for monitoring login attempts and system activity, including:

    • determining who is logged on the system, using the who(1) command

    • finding out which processes are running, using the ps(1) command

    • maintaining logs of system activity, using process accounting commands

  • The ability to encrypt data, using the crypt(1) command .

Security Safeguards and Cautions

Computer security is the responsibility of not only the site administrator, but of everyone who has access to a computer at the site. System users should safeguard their data by using appropriate file and directory permissions in addition to using and guarding their account passwords.

Site administrators, and to some extent system users, should be aware of the following:

  • Anyone with physical access to a computer can simply take it or its disk drives(s).

  • The same caveat applies to backups of the system: keep backups in a secure place. Anyone with physical access to backup tapes can gain access to any information stored on them.

  • Permissions for directories and files should be set to allow only the necessary access for owner, group, and others. This minimizes the damage that one compromised account can cause.

  • There are several ways accounts and passwords protect the system:

    • By requiring users to log in with specific accounts, you can determine who is responsible for specific actions on the system.

    • Using the IRIX system of file permissions, users can keep data reasonably secure. Other users on the system are less likely to accidentally view confidential material.

    • If all accounts have passwords, the chance of an unauthorized person accessing the system is greatly reduced. However, the possibility of unauthorized access increases if users are lax about choosing good passwords and changing their passwords regularly. The next section describes how to choose good passwords.

  • All active accounts need passwords, which should be changed regularly. Do not use obvious passwords, and do not store them online in “plain-text” format. If you must write them down on paper, store them in a safe place.

    For information about choosing passwords, see “ Guidelines for Devising Passwords”.

  • Common-use accounts are a potential security hole. An example of a common-use account is one that is shared by all members of a department or work group. Another example is a standard “guest” account on all the workstations at a site. This allows all users at the site access to different workstations without requiring specific accounts on each workstation.

    A pitfall of common-use accounts is that you cannot tell exactly who is responsible for actions of the account on any given workstation. Another risk is that anyone trying to break into systems at your site will try obvious account names like guest.

    Common-use accounts can be helpful, but be aware that they can pose serious security problems. Needless to say, common-use accounts without passwords are especially risky.

  • Using the last command, periodically monitor who logs into a system. The third field shows the hostname or IP address where remote logins originated; see the last(1) man page .

  • Accounts no longer in use should be either locked or backed up and removed, since unused accounts can be compromised as easily as current accounts.

    Also, change critical passwords, including dialup passwords, whenever anyone leaves the organization. Former employees should not have access to workstations or servers at the site.

  • Systems with dialup ports should have special dialup accounts and passwords. This is very important for sites that have common-use accounts, as discussed above. Refer to the discussion on /etc/d_passwd in “Establishing Second (Dialup) Passwords”.

    However, even with this added precaution, do not store sensitive data on workstations that have dial-up access.

  • If your site allows access to the Internet network (for example, using ftp(1C) ), take precautions to isolate access to a specific gateway workstation. Refer to “About Network Security and Firewalls” in Chapter 5 for details on connecting to external networks.

  • Discourage use of the su(1M) command unless absolutely necessary. This command allows a user to change his or her user ID to that of another user. It is sometimes legitimately necessary to use su to access information owned by another user, but this presents an obvious temptation: the person using su to switch user IDs must know another person's password and therefore has full access to his or her account.

    Note: The file /var/adm/sulog contains a log of successful and unsuccessful attempts (indicated with a minus sign) to use the su command. By default, logging is already enabled in the /etc/default/su file.

  • Make sure that each user's home account, and especially the shell-startup files .profile, or .login and .cshrc, are writable only by that user. This ensures that “trojan horse” programs are not inserted in a user's login files. (A trojan horse program is a file that appears to be a normal file, but in fact causes damage when invoked by a legitimate user.)

  • Be sure that system directories such as / (root), /bin, /usr/bin, and /etc and the files in them are not writable except by the owner. This also prevents trojan horse attacks.

  • If you must leave your console, workstation, or terminal unattended, log off the system. This is especially important if you are logged in as root. Also, refer to the xlock(1) man page for information on locking your local X display.

  • Sensitive data files should be encrypted. The crypt(1) command, together with the encryption capabilities of the editors (ed and vi), provides some protection for sensitive information.

  • Use only that software that is provided by reputable manufacturers. Be wary of programs that are distributed “publicly,” especially already-compiled binaries. Programs that are available on public bulletin board systems (as opposed to BBSs run and sponsored by vendors) and on public computer networks could contain malicious “worm” routines that can violate system security and cause data loss.

    Public-domain source code is safer than already-compiled programs, but only if you examine the code thoroughly before compiling it. Be suspicious of programs that must be installed with set-UID root in order to run.

  • Safeguard and regularly check your network hardware. One possible way to break into computer systems is to eavesdrop on network traffic using physical taps on the network cable. Taps can be physical connections (such as a vampire tap) or inductive taps.

    Run networking cable through secure areas and make sure it is easy to examine regularly. Create and maintain a hard copy map of the network to make it easier to spot unauthorized taps. Another way to make this sort of attack less likely is to use fiber-optic (FDDI) network hardware, which is much more difficult to tap. For details on configuring network software securely, refer to Chapter 5, “Network Security”.

System security under IRIX is primarily dependent on system login accounts and passwords. Proper administration, user education, and use of the facilities provided yield adequate security for most sites. Most security breaches are the result of human error and improper use of the provided security features. No extra measures yield more security if the basic features are not used or are compromised by user actions. Also, for the latest security patches for your system, periodically log in with anonymous FTP to .

For general information about security, go to .

Note: If you are using NFS or NIS on your system, see the discussions in “Disabling NIS (YP) on the Firewall” in Chapter 5 and “Disallowing NFS Access on the Firewall” in Chapter 5.

Password Administration

Th is discussion of password administration includes the following sections:

Managing passwords is also described in IRIX Admin: System Configuration and Operation .

Guidelines for Devising Passwords

Systems are most secure when nobody can access them without both an account and password, and if all the passwords on the system are difficult to guess and obtain. Unfortunately, many users choose passwords that are easy for potential intruders to guess, or write their passwords down on paper left near their workstations.

Also, many site administrators use the same password for multiple administrative accounts. This is not a good practice. Do not deliberately use the same password for more than one account.

More secure passwords are:

  • Long (the first 8 characters are recognized)

  • Multiple words that are combined or arranged in an unusual manner

  • Words from multiple languages, combined in a unique way

  • Composed of different kinds of characters, such as digits and punctuation

  • Have all of these bulleted features

Easily guessed passwords are:

  • Short

  • Single words that are in a dictionary

  • The same as the account name, or the account name spelled backward

  • The name of the user's department or project

  • The user's name or initials

  • The license number of the user's car, a spouse or friend's name, the user's home address, phone number, age, or other obvious information

  • Obvious—for example, “top secret,” “secret,” “private,” “password,” “friend,” “key,” “god,” “me,” and so on

About PROM Passwords

Your system has a facility that allows you to require a password from users who attempt to gain access to the Command (PROM) Monitor. This gives you greater control over who may perform system administration tasks.

Traditionally, if an intruder gains access to your system hardware, there is little you can do to maintain system security. In the simplest case, the intruder switches off the system, then turns it on again, and instructs the system from the console to boot a program other than your usual operating system. Alternatively, the intruder could simply remove the hard disk from your system and install it on another system and read your files. While there is nothing you can do with system software to prevent physical theft of the hardware, you can limit the ability of intruders to boot their programs or to otherwise damage your system at its lowest levels with a PROM password.

Note that if you forget your PROM password, but you still know your root password, you can reset the PROM password on most systems through the nvram command. If you cannot successfully reset the PROM password, you must remove the PROM or a jumper from your CPU board. See your owner's guide for information on this procedure.

To assign a new PROM password if you have forgotten it, first clear the existing PROM password from IRIX with the nvram command, and then assign a new one with the passwd command from the PROM monitor.

Clearing the PROM Password Using nvram

To clear the PROM password using the nvram(1M) command, perform the following steps:

  1. Log in as root.

  2. Give the following command:

    nvram passwd_key “”

    Your PROM password is now cleared.

Setting the PROM Password from the Command Monitor

If you wish to set your PROM password from within the Command Monitor, perform the following steps:

  1. Log in as root and shut down the system.

  2. When you see this message, press the Esc key for the System Maintenance Menu:

    Starting up the system...
    To perform system maintenance instead, press Esc

  3. Select option 5 from the System Maintenance Menu to enter the Command Monitor. You see the Command Monitor prompt:


  4. Type the passwd command and press Enter:


    You see the prompt:

    Enter new password:

  5. Enter the password you want for your system and press Enter. You see the following prompt:

    Confirm new password:

  6. Enter the password again, exactly as you typed it before. If you typed the password the same as the first time, you see the Command Monitor prompt again.Your password is now set. Whenever you access the Command Monitor, you will be required to enter this password.

Refer to “ Guidelines for Devising Passwords” for help in selecting a good password.

Establishing Second (Dialup) Passwords

If your system requires additional protection, you can establish a system password. If you do this, users who log in on specific ports (ttys) are prompted for a system password in addition to their account passwords. This feature cannot be imposed on the system console, or any terminal where clogin or xdm is used.

System passwords are normally used only on dialup lines and are often referred to as dialup passwords. You can use them on standard lines, but this is usually not necessary.

To establish a system password, follow these steps:

  1. Log in as root.

  2. Edit the file /etc/dialups. Place in the file a list of ports (ttys) that require the second password. For example:


    All possible names for ports should be listed, including links. Write the file and exit from the editor.

  3. Decide on the desired password or passwords. System passwords are assigned on a shell-by-shell basis. You can assign the same password for all the possible shells on the system, assign different passwords for each shell, or use some combination of approaches.

  4. Encrypt the desired password. You must use the passwd program to perform the encryption. You cannot use the crypt(1) command for this purpose.

    To encrypt the password, make a backup copy of the /etc/passwd file, then change the password of some account (for example, create a new account called dialup) to get a password for use in /etc/d_passwd. Return the password file to its original state when you are finished, either by restoring the backup copy you made of /etc/passwd, or by removing the dialup account entry. (An account's encrypted password resides in the second field of /etc/passwd, or in /etc/shadow if the second field says x.)

    For example, to change the password of the bin account to ``2themoon'' you enter:

    passwd bin 
    New password:

    Now enter the string 2themoon and then press Enter. The string 2themoon is not displayed as you type it.

    Next you see:

    Re-enter password:

    Enter the string “2themoon” again and then press Enter. The string is still not displayed as you type it.

    Examine the entry for the bin account in the file /etc/passwd. You should see something like this:

    bin:SaXub4uaL5NP:2:2:System Tools Owner:/bin

    The second field (between the first and second colons) is the encrypted version of the password 2themoon. (What you see may be different, even with the same password, depending on the seed the system uses to encrypt the password.)

  5. Edit the file /etc/d_passwd. In the file, place lines in the format:


    The shell variable specifies the command interpreter (shell) you wish to have a password, and password is the encrypted password. Make sure that all shells used in /etc/passwd (the seventh and final field) are listed in this file, including those for UUCP, PPP, SLIP, and so on.

    For example, this command assigns the password 2themoon, which you encrypted in the previous step, to all C shell users who log in on the ttys specified in /etc/dialups:


    You must place a colon at the end of the encrypted password, and you must enter the shell program pathname exactly as it appears in /etc/passwd.

    Write the file and exit from the editor.

  6. Make sure the files have appropriate permissions by issuing the command:

    chmod 640 /etc/d_passwd /etc/dialups 

  7. Remove the password you assigned to the system account in Step 4. To do this, edit the file /etc/passwd and remove the string of characters in the second field. Return this field to the same state as when you began this procedure.

Now, whenever C shell users log in on the ttys specified in /etc/dialups, they are prompted for the system password 2themoon in addition to their account password.

Note that you must make similar entries for any other login shells used on your system such as /bin/ksh, /usr/local/bin/bash, and /usr/bin/tcsh.

About Shadow Passwords

A shadow password file is simply a copy of the standard password file, but it is not accessible by nonprivileged users. In the standard configuration, the /etc/passwd file is publicly readable. Since the /etc/passwd file contains the encrypted versions of users' passwords, anyone can make a copy and attempt decryption of the passwords for malicious purposes. By using a shadow password file, you prevent intruders from attempting to decrypt your passwords.

The shadow password file is called /etc/shadow. Once shadow passwords have been initialized, the password field in each /etc/passwd entry is replaced by an “x” character. All standard password tools work transparently with shadow passwords. The difference should not be noticeable to your users, except that they cannot see their encrypted passwords in the /etc/passwd file.

One exception is that older applications cannot get the proper value of pw_passwd from the getpwent(3C) and getpwnam(3C) library calls. This primarily affects screen saver programs, unless they have root privileges.

Note: Shadow passwords work differently with NIS. See the shadow(4) man page for details on the use of shadow passwords with NIS.

Using a Shadow Password File

To initialize /etc/shadow (and thus invoke shadow passwords), run the pwconv command; see the pwconv(1M) man page . Once this command has been run, shadow passwords are in effect.

To update the password and shadow password files simultaneously, use the passmgmt command; see the passmgmt(1M) man page . The graphical System User Manager can also update shadow passwords if they are in effect.

About Password Aging

The password aging mechanism forces users to change their passwords periodically. It also prevents a user from changing a new password before a specified time interval. You can also force a user to change his or her password immediately.

Note: Password aging is not supported for NIS entries (see the passwd(4) man page ).

Realistically, password aging forces users to adopt at least two passwords for their accounts. This is because, when password aging is enforced, most users alternate between two passwords that they find easy to remember rather than inventing new passwords every time their old ones expire. IRIX does not provide a utility that determines whether users are choosing from a set of passwords and, if so, then forces them to choose completely different passwords.

Controlling Password Aging with the passwd Command

To set the maximum number of days that can elapse before a user must change his or her password, use the passwd(1) command with the following syntax:

passwd -x max  name

The value max is the maximum number of days the password is valid for the user name. For example, this command forces user alice to change her password every 14 days:

passwd -x 14 alice 

If you set max to 0, the user must change her password when she next logs in, but thereafter password aging is not in effect for her. If you set -x to -1, password aging is turned off immediately for that user.

You can also set the minimum time that must elapse before users are allowed to change their passwords. This is useful to prevent users from changing their passwords, then changing them back to their old passwords immediately. For example:

passwd -x 14 -n 7 ralph 

This forces user ralph to change his password every 14 days and prevents him from changing it more frequently than once every 7 days. Note that if you set the minimum value greater than the maximum value, the user may not ever change his or her password.

To force users to change their passwords immediately, use the -f option. For example:

passwd -f trixie 

Controlling Password Aging by Editing /etc/passwd

Another way to enforce password aging is to edit the /etc/passwd file and insert the appropriate information after the password fields in the desired account entries.

Password aging information is appended to the encrypted password field in the /etc/passwd file. The password aging information consists of a comma and up to 4 bytes (characters) in the format:


The meaning of these fields is as follows:


The comma separates the password and the aging information.


The maximum duration of the password.


The minimum time interval before the existing password can be changed by the user.


The week (counted from the beginning of 1970) when the password was last changed and two characters, ww, are used. You do not enter this information. The system automatically adds these characters to the password aging information.

All times are specified in weeks (0 through 63) by a 64-character alphabet. The following chart shows the relationship between the numerical values and character codes. Any of the character codes can be used in the four fields of the password aging information. Table 4-1 lists the password aging codes and their meanings.

Table 4-1. Password Aging Character Codes


Number of Weeks

. (period)

0 (zero)

/ (slash)


0 through 9

2 through 11

A through Z

12 through 37

a through z

38 through 63

Two special cases apply for the character codes:

  • If M and m are equal to zero, the user is forced to change the password at the next login. No further password aging is then applied to that login account.

  • If m is greater than M, only root is able to change the password for that login account.

The following example shows the password aging information required to establish a new password every 2 weeks (0) and to deny changing the new password for 1 week (/) for user ralph:

ralph:RSOE2m.E,0/:100:1:Ralph P. Cramden:/usr/people/ralph: 

After ralph's first login following the change, the system automatically adds the 2-character, “last-time-changed” information to the password field:

ralph:RSOE2m.E,0/W9:100:1:Ralph P. Cramden:/usr/people/ralph: 

In this example, ralph changed his password in week W9. To force ralph to change his password at the next login (and to cause this only once), you can add the code ,.. to the password field:

ralph:RSOE2m.E,..:100:1:Ralph P. Cramden:/usr/people/ralph: 

After ralph changes his password, the system automatically removes the aging code (,..) from the password field. To prevent ralph from changing his password, use the code ,./. Edit the /etc/passwd file and add a comma, period, and slash to the password field:

ralph:RSOE2m.E,./:100:1:Ralph P. Cramden:/usr/people/ralph: 

Now only root can change the password for the ralph account. If ralph tries to change the password, he sees the message permission denied.

Using pwck to Check the Password File

From time to time, you should run the pwck(1M) utility to scan the password file. This program reads the file and checks each entry for completeness and notes any inconsistencies. The password checks include validation of:

  • The number of fields in each entry

  • The login name

  • The user ID number

  • The group ID number

  • The login directory

  • The executed program

The default password file to be checked is /etc/passwd. If shadow passwords (described in “About Shadow Passwords”) are enabled, the /etc/shadow file is checked.

Similarly, the grpck(1M) command verifies all entries in the /etc/group file. The default group file to be checked is /etc/group. With either command, an alternate file may be specified on the command line.

System Login and Account Administration

This section describes how to control special and login accounts. Special accounts are used by the system to perform specific system functions, and login accounts are user accounts allowing general-purpose system access.

About Special Accounts

Special accounts are used by daemons to perform system functions, such as spooling UUCP jobs and print requests. Because key files are owned by these accounts, someone who has obtained access to one of the accounts, or was able to start a daemon on your system, could partially breach security. Partially, because ownership of the various system files is distributed among the special accounts.

Guard access to all the special accounts as you would the root account. Either assign passwords to these accounts, or lock them using one of the methods described in “ Locking Unused Logins”.

Following is a list of all the administrative and special accounts on the system and what they are used for:


This login has no restrictions, and it overrides all other logins, protections, and permissions. It allows you access to the entire operating system. The password for the root login should be very carefully protected.


This login has the power of a normal user login over the files it owns, which are in /usr/src. Its login should be disabled.


This login has the power of a normal user login over the files it owns, which are throughout the system. Its login should be disabled.


This login has the power of a normal user login over the files it owns, which are located in /var/adm. You may use the su command to connect to the adm login. This login should be disabled.


This login owns the object and spooled data files in /usr/lib/uucp and /etc/uucp.


This login is used by remote workstations to log into the system and initiate file transfers through /usr/lib/uucp/uucico.


This login is the system daemon, which controls background processing. Its login should be disabled.


This login owns the object and spooled data files in /var/spool/lp. Its login should be disabled unless the system is a print server.

Locking Unused Logins

If a login is not used or needed, disable (lock) the login. You should not remove the account, though, because of the danger of reusing the UID in the future. User ID numbers are meant to be permanently associated with the person who used the account. If you reuse the UID number, the new user may find files that belonged to the previous owner of the ID number. These files may contain “trojan horse” programs that could damage your system. You may remove the user's home directory and files (after making a backup), but you should never remove an entry from your /etc/passwd file.

There are two ways to lock an account. The first is using the passwd command with the -l option. For example, the current entry in /etc/passwd for the user jones might look like this:

jones:6.D/N3ZFGmq7U:3333:10:Jeremiah Jones:/usr/people/jones:/bin/tcsh

The following command changes the password field of the entry in /etc/passwd for account jones to *LK*, which blocks all logins to that account:

passwd -l jones

The password field entry now looks like this:

jones:*LK*:3333:10:Jeremiah Jones:/usr/people/jones:/bin/tcsh

The second way to lock an account is by editing the password file directly. Change the password field to any string of characters that is not used by the password encryption program to create encrypted passwords. The passwd command with the -l option uses the string *LK*. You can use other strings to lock accounts.

For example, you can use a descriptive phrase such as “LOCKED;” to remind you that the account was deliberately disabled:

ralph:LOCKED;:100:1:Ralph P. Cramden:/usr/people/ralph: 

The semicolon is not used in an encrypted password and causes the account to be locked. The text “LOCKED” is merely to remind you that the account is locked.

Another common method of disabling a password is to put an asterisk (*) in the password field. The default IRIX /etc/passwd file disables some unused logins this way.  Be sure to check your /etc/passwd file to be sure all logins have passwords or are disabled.

System Login Options

You can set the following login options to enhance security:

  • Restrict root logins to a specific device, typically the system console.

  • Specify the number of times an attempt to log in can fail before the login exits.

  • If the login process is disabled, specify how long before it can be resumed.

  • Specify whether to maintain a log of logins and what information to store: all logins or only those that were unsuccessful.

  • Specify whether to force a user who does not have a password to choose one immediately upon logging in.

  • If a login fails after the specified maximum number of attempts, disable the account by locking the password, with possible exceptions including the root account.

  • Specify whether or not to display, after successful login, the date and time when the user last logged in.

Login options are set in the file /etc/default/login, which is a normal text file. The file contains one option specification per line. Options are described in the rest of this section. See the login(1) man page for further details.

Because the login procedure is your system's main defense against unauthorized access, login options are important. For example, you can determine whether someone is trying to break into your system from a pattern of failed login attempts recorded in /var/adm/SYSLOG (when logging is enabled, which is the default).

The best way to keep a system secure is to slow down attempts to guess passwords and account names. The login options described in this section add delays to unsuccessful login attempts, which drastically curtails the activity of randomly guessing passwords.

Note that the visual login process clogin(1) does not provide these security options. To use the login security functions, you must turn off clogin and use the standard login processes, getty(1) and login(1) . Use chkconfig to turn off the visuallogin and xdm configuration variables. See IRIX Admin: System Configuration and Operation and the visuallogin(4) man page for information about turning the visual login process on and off. You may also use chkconfig to set the noiconlogin variable to disallow logging in using the user icons in clogin.

Restricting root Logins

You can restrict root logins to a single device, forcing root users to either use that device or use the su command (thereby leaving a trail in /var/adm/sulog). For example, edit /etc/default/login to include the following line to restrict root logins to the system console:


Note: Do not name /dev/syscon or /dev/systty as the device! These devices are the same as /dev/console, but login software does not treat them alike.

Restricting Login Attempts (MAXTRYS)

MAXTRYS is the number of times a login attempt can fail before retracting the login. Setting this parameter slows attempts by unauthorized persons to break into a system.  A common method of breaking into a system is to try to guess the password of a known account. This method is most successful if the person trying to break in knows the names of as many accounts as possible, and can make guesses very quickly. If you introduce a delay in the login process after a certain number of failed login attempts on the same tty line, you can make it much more time-consuming to guess a password correctly.

To set the maximum number of login attempts, edit the file /etc/default/login. Place a line like this in the file:


This sets the maximum number of login attempts to four (the system default, without this option set, is three).

When the maximum number of login attempts is exceeded, the login program sleeps for a certain number of seconds (the DISABLETIME variable described in the next section), thus preventing further login attempts on that line for a while. The system default delay (DISABLETIME) is 20 seconds. This example login attempt was disabled after three tries:

login: guest
Login incorrect
login: guest
Login incorrect
login: guest
Login incorrect

At this point, no further login prompts are displayed until the period of time specified by DISABLETIME has passed.

Setting a Time Period to Disable a Line (DISABLETIME)

Use this option together with the MAXTRYS option. To set the number of seconds after which a certain number of unsuccessful login attempts a line is disabled, edit the file /etc/default/login and add a line like this:


This disables a line for 30 seconds. You can choose any value you consider appropriate for your system. The system default is 20 seconds.

Recording Login Attempts

Both successful and unsuccessful login attempts are usually recorded in the file /var/adm/SYSLOG. The default setting, which causes the system to record all attempts to log in, even successful ones, is this line in the file /etc/default/login:


To record only unsuccessful login attempts, replace that line with this line:


A large number of failed logins, especially with the same account name, may indicate that someone is trying to break into that account and thus into the system. Security event auditing could help here; see Chapter 6, “Administering the System Audit Trail”.

Forcing a Password

To force users without account passwords to choose their passwords immediately, add this line to the file /etc/default/login:


Or instead, insert the following entry to prevent users from logging in if they do not already have a password:


Disabling Accounts (LOCKOUT)

LOCKOUT specifies the number of consecutive unsuccessful login attempts by a user after which the account is locked with passwd -l username. (See “ Locking Unused Logins” for information about account locking.)

If you set the LOCKOUT option, it is best to exempt at least the root account with the LOCKOUTEXEMPT option to prevent denial of service attacks; see the login(1) man page .

Displaying the Last Login Time

Users can help maintain system security by noticing unauthorized use of their accounts. By default, the most recent login date, time, and the name of the terminal line (tty name) or remote host from which the user logged in is displayed on login. This login attempt information is recorded in files, one per user account and with the same name as the account, in the directory /var/adm/lastlog.

Users can stop the last login information from being displayed by having a .hushlogin file in their home directory, but they should be discouraged from doing so. Remind them periodically to look at the information each time they log in for any unusual information.

About Set-UID and Set-GID Permissions

The set user identification (set-UID) and set group identification (set-GID) permissions must be used very carefully. When a user runs an executable file that has either of these permissions, the system gives the user the permissions of the owner of the executable file. You can add these permissions to any executable file with the chmod(1) command.

Set-UID and set-GID programs have legitimate uses, but because they are potentially harmful, there should be very few of them on your system. Beware of programs in publicly writable directories (such as /tmp, /usr/tmp.O, /var/tmp, and /usr/spool/uucppublic) that have the same name as common systems files (such as vi and rm). One reason the PATH environment variable of the root account does not include the current directory (as does the default PATH of most other users) is so that root will not accidentally execute such “booby-trap” programs.

System security can be compromised if a user copies another program onto a file with -rwsrwxrwx permissions. To take an extreme example, if the su command has the write access permission allowed for others, anyone can copy the shell onto it and get a password-free version of su.

The following sections provide some example commands that identify files on the system with set-UID permissions. For more information about the set-UID and set-GID bits, see the chmod(1) and chmod(2) man pages.

Checking for Set-UID Files Owned by root

The following command line lists all set-UID files owned specifically by root:

find / -user root -perm -4000 -print

The results of this command are printed on the screen. All paths are checked starting at /, including all mounted directories. A great number of files will be found. It is up to you to scan these files for any unusual names. One possibility is to direct the output of this program to a file soon after installation and compare the results with later outputs. If this command reports any unusual files, investigate them immediately.

A suspicious file might turn up like this:

-r-sr-xr-x 1 root  bin   38836 Aug 10 16:16 /usr/bin/at 
-r-sr-xr-x 1 root  bin   19812 Aug 10 16:16 /usr/bin/crontab 
-r-sr-xr-x 1 root  bin   27748 Aug 10 16:16 /usr/bin/shl 
---s--x--x 1 root  sys   46040 Aug 10 15:18 /usr/bin/ct 
-r-sr-sr-x 1 root  bin   33208 Aug 10 15:55 /usr/lib/lpadmin 
-r-sr-sr-x 1 root  bin   38696 Aug 10 15:55 /usr/lib/lpsched 
---s--x--- 1 root  user  45376 Aug 18 15:11 /usr/jbond/bin/sh 
-r-sr-xr-x 1 root  sys   11416 Aug 11 01:26 /bin/mkdir 
-r-sr-xr-x 1 root  sys   11804 Aug 11 01:26 /bin/rmdir 
-r-sr-xr-x 1 root  bin   12524 Aug 11 01:27 /bin/df 
-rwsr-xr-x 1 root  sys   21780 Aug 11 01:27 /bin/newgrp 
-r-sr-sr-x 1 root  sys   23000 Aug 11 01:27 /bin/passwd 
-r-sr-xr-x 1 root  sys   23824 Aug 11 01:27 /bin/su 

In this example, the user jbond has a personal copy of /bin/sh and has made it set-UID to root. This means that anyone in the group user can execute /usr/jbond/bin/sh and become the superuser.

Checking for Set-UIDs in the root Filesystem

The following command line reports all files with a set-UID for the root filesystem (not just those owned by root) on EFS filesystems:  

ncheck -s /dev/root | xargs ls -ld | cut -f2 | grep -v ~/dev/ 
ls -l `/etc/ncheck -s /dev/root | cut -f2 | grep -v dev` 

The ncheck(1M) command, by itself, can be used on a mounted or unmounted file system. Only the superuser may use ncheck. The normal output of the ncheck -s command includes special files. Here, the grep command removes device files from the output. This filtering is applicable only for the root filesystem. The output of the modified ncheck is then used as an argument to the ls command. The filesystem must be mounted for the ls command to succeed. In this example output, nothing looks suspicious:

-r-sr-xr-x  1 root   bin    12524   Aug 11 01:27 /bin/df 
-rwxr-sr-x  1 root   sys    32272   Aug 10 15:53 /bin/ipcs 
-r-xr-sr-x  2 bin    mail   32852   Aug 11 01:28 /bin/mail 
-r-sr-xr-x  1 root   sys    11416   Aug 11 01:26 /bin/mkdir 
-rwsr-xr-x  1 root   sys    21780   Aug 11 01:27 /bin/newgrp 
-r-sr-sr-x  1 root   sys    23000   Aug 11 01:27 /bin/passwd 
-r-xr-sr-x  1 bin    sys    27964   Aug 11 01:28 /bin/ps 
-r-xr-sr-x  2 bin    mail   32852   Aug 11 01:28 /bin/rmail 
-r-sr-xr-x  1 root   sys    11804   Aug 11 01:26 /bin/rmdir 
-r-sr-xr-x  1 root   sys    23824   Aug 11 01:27 /bin/su 
-r-xr-sr-x  1 bin    sys    21212   Aug 10 16:08 /etc/whodo 

For XFS filesystems, use the find command:

find / -perm -4000 -print

Checking Set-UIDs in Filesystems Other Than root

This example uses the ncheck command to examine the /home partition (/dev/dsk/dks0d2s7 in this example) for files that have set-UID permissions:

/etc/ncheck -s /dev/dsk/dks0d2s7 | cut -f2 

In the output below, the inode number is given with complete pathnames for files, which start with /home, although /home is not part of the ncheck output.

3971    /jbond/bin/sh

In the ncheck output, the program /home/jbond/bin/sh should be investigated. This program is not found in a system directory. It is a command shell residing in a user's home directory. Users should, in general, not possess set-UID binaries.

About General File and Directory Permissions

Be conservative when establishing or changing permission bit settings on all files and directories. The safest settings do not allow write access, but where this is not possible, it may be possible to limit write access to the owner of the file or directory, or at least just to the owner and the group.

The following files and directories are universally available for read and write access on IRIX as shipped. Depending on your site requirements, you may wish to change the permissions on these files to be more restrictive. See the chmod(1) man page for a discussion on setting the sticky bit on such directories as /tmp (this is the IRIX default) to restrict removal and renaming of files.

  • /tmp

  • /usr/demos/.xsession 

  • /usr/Insight/tmp 

  • /usr/Insight/tmp/ebtpriv 

  • /usr/Insight/tmp/ebtpub 

  • /usr/Insight/tmp/install.insight.log 

  • /usr/lib/emacs/maclib 

  • /usr/lib/showcase/fonts 

  • /usr/lib/showcase/images 

  • /usr/lib/showcase/models 

  • /usr/lib/showcase/templates

  • /usr/tmp.O

  • /var/spool/locks 

  • /var/spool/uucppublic 

  • /var/tmp 

    Caution: Restricting permissions on historically open directories, such as /tmp, /usr/tmp.O, and /var/tmp (linked to /usr/tmp), can cause serious malfunctions in many programs, applications, and system utilities that write temporary files on behalf of users in these directories.

Systems should not be running the rfindd daemon, because it allows external access to file, directory, and permissions listings. See rfindd(1M) for more information.

/etc/shells database

The /etc/shells is an ASCII file containing the list of shells on a system. The sendmail(8) program uses /etc/shells to decide if it is going to deliver a user's mail to a process via a pipe. If the user's shell is not listed in /etc/shells, the mail will be bounced. For more information, see the shells(4) man page.

If a user is allowed to change his or her shell either via yppasswd(1) or ypchpass(1) the new shell path is checked against the default list of known shells on a NIS master. This list can be changed by creating the file /etc/shells, where each line corresponds to one shell path (see the rpc.passwd(1M) man page.

Accounts Shipped Without Passwords

The following accounts in your default /etc/passwd file are shipped without passwords. You should create passwords for at least the root account immediately.

  • root—Superuser

  • lp—Print spooler owner

  • nuucp—Remote UUCP user

  • EZsetup—System setup

  • demos—Demonstration user

  • OutOfBox—Out-of-box experience

  • guest—Guest account

  • 4Dgifts—4Dgifts account

    Caution: Creating passwords on historically open accounts, such as lp, may cause certain related applications or operations to fail.

Security File and Command Reference

This section summarizes in two tables some IRIX files and commands that establish and control security. Table 4-2 lists the IRIX files concerned with security and Table 4-3 lists security-related commands.

Table 4-2. IRIX Security Files





Control login actions



Define su command defaults



Store password and account information

passwd(1) , passwd(4)


Hide password information

shadow(4) , pwconv(1M)


Log su command usage



Log system messages


Table 4-3. IRIX Security Commands

Command Example



arp -a

Display current ARP entries

arp(1M) , arp(7P)

crypt password

Encode/decode input/output



Indicate last logins of users and terminals



Generate pathnames from i-numbers



Change password

passwd(1) , passwd(4)

ps -elf

Display a full, long list of every process currently running



Report inconsistencies in /etc/passwd file

pwck(1M) , passwd(4)


System activity reporter

sar(1) , sadc(1M)


Reliably save the system audit trail

satd(1M) and “Placing the Audit Files” in Chapter 6


vi -x

Edit encrypted file

vi(1) , crypt(1)


Display users logged in with current activity



Display users logged in, their tty, and time of login


Enhanced Security Features

IRIX 6.5 and later releases include enhanced security features from Commercial Security Pak, namely access control lists (ACLs) and least-privilege capabilities.

Access Control Lists (ACLs)

An ACL works in the same way as standard file permissions, but it allows you to get 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 access control list 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 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 on both ACLs and must be allowed by IRIX file permissions to successfully gain access. If you have not created an access ACL for a file, the default ACL serves both ACL functions.

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 -D option to ls(1) as shown in this example:

ls -D /usr/people/ernie/testfile 

The command above produces output similar to this:

testfile [user::rwx ,user:332:r--,user:ernie:rw-] 

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 “Long ACL Text Form”.

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

chacl acl_entry[,acl_entry]...

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.

Long ACL Text Form

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


Though 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 must contain exactly one each of the following characters in the following order:


Read access.


Write access.


Execute access.

Any or all of these may be replaced by the no-access dash(–).

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 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 crosshatch (#) 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.

If an ACL entry contains permissions that are not also contained in the umask entry, then the output text form for that entry must be displayed as described above followed by a crosshatch (#), the string “effective:“ and the effective file access permissions for that ACL entry.

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 crosshatch (#) comment character

  • At any point after the first crosshatch (#) 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

Short ACL Text Form

The short text form is used by the chacl(1) command for input of ACLs, and is set up as follows:


Though 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 command line contains one ACL entry, with the exception that the ACL entry tag type keyword must appear in the first field in either its full unabbreviated form or its single-letter abbreviated form.

The abbreviation for user is u, the abbreviation for group is g. The abbreviation for other is o, and the abbreviation for mask is m.

There are no exceptions for the second field in the short text form for ACLs. The discretionary access permissions must appear in the third field in either absolute symbolic form or relative symbolic form.

The relative symbolic form must be preceded by a plus sign (+) to indicate additional access or a caret (^) to indicate that access is to be removed. The relative symbolic string must be at least one character.

The symbolic string contains at most one each of the following characters in any order:

  • r

  • w

  • x

For example, the short form should 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:^w # 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. 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 this example:

ls -dD testdir 

The command given above produces the following output:

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

Create a new directory (it does not matter where) with this command:

mkdir newdir 

Then use the following command to edit and copy the ACL (give this command all on one line):

chacl -b `ls -dD testdir | cut -d"[" -f2 | cut -d"/" -f1``ls -dD testdir | cut -d"[" -f2 |  cut -d"/" -f2 | cut -d"]" -f1`newdir 

The ACL from testdir will be replicated in newdir. Note that the cut command is used within the above command line. For complete information on the correct use of cut in any command line, see the cut(1) man page. After giving the above command, an ACL listing of newdir shows that the ACL from testdir has been duplicated:

ls -dD newdir 
newdir [u::rwx,g::r-x,o::--x/u::rwx,g::r-x,o::---] 

Note that the cut and paste functions of the window manager can also be used to duplicate ACL entries from ls -D to chacl.

Least-Privilege Capabilities

Capabilities are privileges assigned to specific accounts to allow those accounts to perform operations formerly reserved to the superuser. To maintain the principle of least privilege, the capabilities of the superuser account can be subdivided into various capabilities, which can be assigned to separate individual accounts. The corresponding capability is placed on sensitive executable files and programs on your system. Account capability and executable capability must be compatible for the user to execute the program. For a more technical discussion, see the capabilities(4) man page.

The fundamental purpose of capabilities is to allow you to perform administration tasks from standard login accounts without requiring the use of Superuser or other privileged accounts. A capability endorsement may be granted to any user account, and a corresponding capability requirement attached to only those system objects that the owner of the endorsed account has a legitimate need to use. This follows the trusted systems principle of least privilege—using the lowest possible promotion of privileges necessary to get the job done. Capabilities implement least privilege both by limiting the number of users privileged to perform various tasks and by limiting the privilege to just one program, or section of code within, necessary to perform the proper action.

It is usually inappropriate to grant capabilities to ordinary users of the system. Should you decide to do so, remember the principle of least privilege: A user should have only those capabilities for which a need can be demonstrated and no others.

Capabilities provide fine-grained control over the privileges of a process. A process can be granted specific capabilities to perform privileged system calls, but not be granted general override of the system's protection scheme as is the case with a setuid root program. The IRIX capability mechanism is designed to comply with Draft 15 of the POSIX P1003.1e Draft 15 specification.

The /etc/capability File

The file /etc/capability is the database of capabilities for user accounts. Here is an example:

casey:all=:all+eip # We trust Casey. 
jeff:all+eip CAP_NETWORK_MGT-eip:all+eip 

Each entry consists of up to three colon-separated fields, as follows:

username : default_capability : maximum_capability 

  • The username is the user's login name. This must be exactly the same as that found in the /etc/passwd file.

  • The default_capability set is applied at login time to the user's shell process. A user may request additional capabilities at login time. If capabilities not present in this entry are requested at login time, the login attempt will fail.

  • The maximum_capability field describes all those capabilities that may be requested and received by the user's processes.

The default and maximum capability fields are of the following form:

capname,capname operator flags 

The capname element(s) are taken from the list of capabilities supplied in the section titled “Capabilities in This Release”.

The operator can be any one of the following:


Add this capability (or list of capabilities) to the following sets.


Delete this capability (or list of capabilities) from the following sets.


Revoke this capability (or list of capabilities) for the duration of this process for the following sets.

The flags that represent the capability sets are one or more of the following:


Inheritable set of capabilities: the capabilities that can be passed to child processes.


Effective set of capabilities: the capabilities currently active.


Permitted set of capabilities: the maximum set of capabilities for the process.

Each field contains a list of clauses. Each clause is a space-separated list of capabilities and an operator/set statement. All characters after # to the end of the entry line are interpreted as comments and are ignored. The clauses are interpreted sequentially, as read (left to right). This means that the last operation specified for a capability within an entry is the one that counts.

Now look at the sample /etc/capability file again:

casey:all=:all+eip # We trust Casey. 
jeff:all+eip CAP_NETWORK_MGT-eip:all+eip 

In this sample file, note the following:

  • The root account has all capabilities added by default with all flags.

  • The auditor account has only those capabilities necessary to manage the system audit trail, and the capability to kill processes.

  • The ernie account has no default capabilities, but if necessary can acquire the capabilities to work on other people's files and set capability requirements for executable files.

  • The casey account has no default capabilities, but can acquire full capabilities if necessary. There is also a comment to that effect.

  • The jeff account has a default set of full capabilities, modified by a subsequent clause to delete the network management capability. However, Jeff can request a full capability set if needed.

  • The fred account has no capabilities, nor can Fred request any.

Every running process has three capability sets: effective, permitted, and inheritable.

  • The effective set is used in access control decisions for that process.

  • The inheritable set is used in the calculation of new capability sets during exec(2) processing, when a user invokes an executable file.

  • The permitted set is the maximum set of capabilities that the process may attain.

Each executable file has the same three capability sets as well. These sets influence the final effective capability set of the new process created when a user invokes the program.

  • The new effective set is the intersection of the permitted set of the parent process and the executable file's effective set. That is, if the executable file's effective set of capabilities includes a capability that is within the permitted set of the calling process, but not within that process' effective set, the capability will be added to the child process' effective set.

  • The new inheritable capability set is the intersection of the inheritable capabilities of the calling process and the inheritable capability set of the executable file. That is, only those capabilities that are inheritable by the executable file and are designated inheritable by the parent process will be inheritable in the new process.

  • The new permitted capability set is the union of the executable file's permitted set and the intersection of the new inheritable set and the parent process' permitted set. That is, all permitted capabilities of both the file and the parent process are permitted so long as each capability is inheritable by both the parent process and the executable file.

The effective capability set of the parent process does not influence any of the new sets, and the executable file's inheritable set defines an upper bound on the capabilities available to the new process.

Capabilities in This Release

The following capabilities are shipped in this distribution:


Indicates all capabilities.


Privilege to issue accounting setup system calls such as acct(2) .


Privilege to manage the system audit trail such as the sat_read(2) and sat_write(2) system calls.


Privilege to write to the system audit trail such as the sat_write(2) system call.


Privilege to change the owner of a file not owned by the process and with the system configured for _POSIX_CHOWN_RESTRICTED on changing file ownership.


Privilege to execute the chroot(2) system call.


Privilege to execute a file when the permissions or access control list would prohibit it.


Privilege to read a file or search a directory even though the permissions or access control list would prohibit it.


Privilege to write a file or update a directory when permissions or Access Control Lists would have prohibited it.


Privilege to issue restricted device management calls and ioctl actions such as the following:

  • XLV logical volume interface —Defines logical volumes and various parameters about them.

  •  syssgi(SGI_FS_INUMBERS) —Returns all the valid internal handles (inode numbers) on an XFS file system.

  • syssgi(SGI_FS_BULKSTAT) —Returns file status (struct stat) “in bulk” for an entire file system.

  • fcntl(F_FSSETDM) —Sets the DMA parameters for a file.

  • DMI interface —Used by tertiary storage management products.

  • Set the CLOCAL flag on a port marked CD_MODEM using ioctl with TCSETA, TCSETAF or TCSETAW control parameters.

  • Perform privileged operations on a disk using ioctl.

  • Access to the hardware performance monitor using syssgi(2) .

  • Load, unload, register and unregister loadable device drivers, streams modules, and file systems (mload(4) ).

  • Revoke access to a device using vhangup(2) .

  • Control memory error handling using syssgi(2) .

  • Establish a user level interrupt handler (uli(3) ).

  • Get and set file system attributes.


Privilege to operate on a file as if the process owned it. This capability overrides the requirement that the user ID associated with a process be equal to the file owner ID, except in the cases where the CAP_FSETID capability is applicable. In general, this capability, when effective, will permit a process to perform all the functions that any file owner would have for their files.


Privilege to set the setuid or setgid bits of a file without being the owner. Also, the privilege to change the owner of a file with setuid or setgid bits set. This capability overrides the following restrictions:

  • That the effective user ID of the calling process shall match the file owner when setting the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits on that file.

  • That the effective group ID or one of the supplementary group IDs of the calling process shall match the group ID of the file when setting the set-group-ID bit of that file.

  • That the set-user-ID and set-group-ID bits of the file mode shall be cleared upon successful return from chown.


Privilege to send a kill(1M) signal to another process not owned by the sender. Also, privilege to use process synchronization calls (procblk) to a process.


Privilege to issue restricted memory management calls, primarily memory locking. This capability overrides the restriction that a process may not manipulate the system memory management policies. The operations enabled by this capability include the following:

  • Lock or unlock a shared memory segment via the shmctl(2) interface.

  • Lock or unlock other segments of a process in memory (mpin(2) , plock(2) ).

  • Use of the syssgi(SGI_MINRSS) system call.

  • Retrieve the physical address of a page.


This is an alias for CAP_DEVICE_MGT.


Privilege to issue the mount(2) and umount(2) calls.


Privilege to issue restricted networking calls, such as setting the network interface address, and network interface device management. This capability is required to change the system network configuration. The functions enabled by this capability include:

  • Downloading firmware to network device interfaces and starting them.

  • Setting the Media Access Control (MAC) address; for example, the Ethernet address of an interface.

  • Retrieving device management information from network devices.

  • Setting, controlling, and examining the FDDI SMT information.

  • Controlling the ARP mechanism.

  • Controlling the IP address(es), parameters, and flags of network interfaces.

  • Configuring the IP filter.

  • Using the private interface for lockd(1M) .

  • Using the private interfaces for the NFS service daemons.


This is an alias for CAP_SYSINFO_MGT.


Privilege to open a socket on a privileged TCP port.


Privilege to issue restricted process management calls. This capability is required to override the restrictions on changing the attributes of other processes and to perform privileged process operations. These include the following:

  • Tracing a setuid/setgid executable.

  • Setting resource limits larger than system or per-process limits.

  • Using the kernel thread facilities.

  • Updating the real UID/GID within a share group (without this capability, effective IDs are updated) when the UID or GID is changed.

  • Setting the per-process stack size in a share group using prctl(2) .

  • Forcing the process to be resident prctl(2) .


Privilege to issue restricted disk quota management calls.


Privilege to issue restricted scheduler calls such as real time scheduler interfaces. This capability is required to manipulate the system process scheduler. Operations enabled by this capability include

  • Changing the process priority to a high value

  • Changing the process priority of another process

  • Setting the process to have non-degrading priority

  • Setting the real-time priority of a process

  • Setting the time slice value for a process

  • Controlling the association of processes to processors

  • Setting the working set priority for a process

  • Using the Frame Rate Scheduling features

  • Altering the process resource limits

  • Controlling the rate at which the buffer cache flush routine operates


This is an alias for CAP_SETFPRIV.


Privilege to alter the capability set of a file.


Privilege to change the real, effective, and saved GID of the process. Also the privilege to change the process group ID.


This is an alias for CAP_SETPPRIV.


Privilege to alter the capability set for a process.


Privilege to change the real, effective, and saved UID of the process.


Privilege to shut the system down or reboot it. This capability is required to use the uadmin(2) system call, which can:

  • Shut the system down

  • Reboot the system

  • Force remount of the root after automatic file system damage repair

  • Notify all processes to terminate gracefully

  • Power down the system (not supported on all systems)


Privilege to issue restricted STREAMS calls and operations.


Privilege to issue the swap(2) call.


Privilege to set system information such as hostname and the NVRAM values. This capability is required to manipulate the system identification information of the system. This includes the following:

  • NVRAM contents on adapters such as the FDDI interface (typically addresses or names).

  • Host ID, node name, and domain name.

  • Activate VM fault tracing.

  • Control the treatment of UID 0:

    Conventional superuser: UID 0 has all privileges, capabilities are not used.

    Modified superuser: capabilities are used, but root does not require them. When root does an operation that would have needed capabilities, a record is kept.

    No superuser mode: UID 0 and the root account are not special.

  • Change system tuning parameters.

  • Invoke the internal kernel debugging support.

  • Set the automatic power-on time.

  • Set the machine ID (serial number).


Privilege to set the system time. This capability is required to modify the system clock. This includes the following functions:

  • Set the time trim adjustment (used for clock synchronization with external sources).

  • Adjust the system clock.

  • Set the system clock.

  • Enable the fast clock.

  • Control which processor will handle clock interrupts.

File Capabilities

Capabilities on a file are only meaningful for executable files on XFS format file systems. Capability requirements on files can be set by the System Administrator with the chcap(1M) command. The syntax is as follows:

chcap CAP, CAP, CAP file 

For example, suppose you want to set capabilities to match those associated with the auditor account:


Use this command:


To list the capability requirements of a file or directory, use this command:

ls -P

The -P flag stands for “privilege.” Note that you must have the appropriate capabilities to read the file in order to read the capabilities of the file.

Creating Custom Capabilities

You can create unique capabilities at your site. Simply add the capability tag you want (it must be unique) to your /etc/capability file on the line for the user or users who are to have the capability, then use the chcap(1) command to add the capability to the files you desire.

Using attrinit to Clean Up Capability Corruption

If you believe you have experienced corruption of some capability requirements on files or directories , you can use the attrinit(1) command to restore those capability requirements.

The /etc/irixcap file is used with the attrinit command as follows:

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

  2. Next, give this command:

    attrinit -script=/etc/irixcap 

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

Pluggable Authentication Modules

Pluggable Authentication Modules (PAM) are a suite of shared libraries that enable the local system administrator to choose how applications authenticate users. In other words, without rewriting and recompiling a PAM-aware application, it is possible to switch between the authentication mechanism(s) it uses. You may entirely upgrade the local authentication system without touching the applications themselves.

The PAM implementation on IRIX has been ported from Open-Source Linux-PAM. For additional information go to this location:

By default, PAM is configured off during system installation. You can configure PAM on across system reboots by using the chkconfig(1M) utility as follows:

# chkconfig pam on