Domain/OS Protection

The SR10 Domain/OS protection model incorporates UNIX semantics and extends them with Access Control Lists (ACLs). The Domain/OS model is thus a superset of the UNIX model, as shown in Figure 5-2.

Domain/OS Protection

UNIX Protection

Figure 5-2. Domain/OS and UNIX Protection

5.2.1 ACL Structure

Each file system object has an ACL that defines who can perform what operations on that file or directory. An ACL contains a number of entries. Each ACL entry has two parts: a Subject Identifier (SID) and a set of access rights.

Subject Identifiers

An SID is a specifier consisting of fields for a person, a group, and an organization. In ACL entries, each field of the SID can be either a name or a wildcard (%). Section 4.2 describes SIDs in more detail.

Access Rights

Access rights describe the extent of an SID's access to the associated object. Table 5-2 lists the access rights for files and directories.

Table 5-2. Domain/OS Access Rights

Access File Directory

r Read List entries

w Write Add, delete, or change

entries (including links)

x Execute Search

p Change protection Change protection

k Keep (prevents deletion Keep (prevents deletion or change of name) or change of name)

The r, w, and x rights are like their UNIX counterparts.

In vanilla UNIX systems, only the owner of an object or the super-user can change the object's protection. However, in Domain/OS, you can use the p access right to grant any SID permission to change the object's protection.

The k right in an ACL entry denies the specified SID the right to delete the object or to change its name, even if that SID has write permission for the parent directory. Under traditional UNIX semantics, all objects in a writable directory are deletable. However, in some situations, you want a directory to be writable, but you want to protect a particular file or subdirectory from deletion. You can establish this protection by setting the k right in the ACL for the file or subdirectory.

5.2.2 Types of ACL Entries

An ACL must contain four required entries; in addition, ^it can contain extended entries.

The required entries, which express UNIX protection information, are stored in the i-node of each file or directory to provide rapid access for operations like stat and chmod.

Required Entries

Every ACL contains at least four entries: one each for person, group, organization, and world. These are the four required entries in an ACL. The person, group, and world entries correspond to the UNIX concepts of owner, group, and other. The organization entry does not have a UNIX analog.

A required ACL entry can be designated as an ignored entry. When the operating system checks permission to access the object, it ignores the entry. The ad command displays the entry with the word "ignored" in place of the access rights.

The SIDs in the four required entries must be of the forms person. %. %, %.group. %,

%. %. organization , and %. %. %.

Extended ACL Entries

In addition to the four that are required, an ACL can contain up to 22 extended entries.

As we will explain in Subsection 5.3.2, the operating system applies a mask to the rights specified in extended entries when it checks permissions.

The SIDs in extended entries can specify any combination of person, group, and organiza-tion, provided they do not duplicate any SIDs in the required entries. An extended entry cannot be ignored.

An Example

Figure 5-3 shows the ACL for a file as reported by the ad command. The left column shows SIDs; the right column shows the access rights associated with each SID.

NOTE: All examples in this chapter use the ad utility. If you are working in a purely SysV environment (that is, you do not have alcorn directory), use the lsad command (see the Is ad manual page).

$ ael bar entries for owner, group, organization, and world.

The file ACL controls access to the file with which it is associated.

The directory ACL controls access to the directory with which it is associated.

The initial file ACL determines the protection for files created within a directory.

The initial directory ACL determines the protection for subdirectories created within a directory.

Initial ACLs determine the protection assigned to newly created files and directories.

Subsection 5.2.5 discusses in detail the role of initial ACLs.

Figure 5-4 illustrates the rules for ordering of ACL entries. the output of the ad command; ad displays extended entries separately from required entries. Figure 5-5 shows the same ACL, as ad would display it.

• The protection mode, if any, specified by the program creating the object process, as Subsection 5.1.4. explains.

In Domain/OS, the low-order octal digit in the mode and the umask applies both to the

Figure 5-6. Initial File ACL Implementing BSD Inheritance

The edad command has options that set inheritance of ownership or permissions in the initial ACLs of a directory. However, you should not ordinarily need to use these options;

when Domain/OS software is installed on your node, the initial ACLs of your directories are set to implement the inheritance mechanism appropriate for your environment. The chad command allows you to change easily the inheritance semantics for any particular directory.

5.2.6 Utilities

This subsection surveys the utilities that deal with ACLs.

The Aegis operating environment provides the utilities ad and edacl. You can use ad to display an ACL or to copy an ACL from one object to another. You can use edad to edit ACLs.

In all three of the operating environments, the utilities chad, lsad, and cpad are available in /usr/apollo/bin. These tools offer functionality similar to that of the Aegis ad and edad utilities but user interfaces similar to those of the UNIX chmod, Is, and cp utilities.

If you use BSD or SysV UNIX protection without any of the Domain/OS extensions, you will not need to deal with ACLs at all. See Subsection 5.1. 5 for a survey of the UNIX protection utilities.