Mode Bits for New Objects That Do Not Inherit ACLs

· The UNIX mode bits specified at the system call level (with the UNIX open( ), creat( ), or mkdir( ) system call) when the object is created. The application that invokes one of these system calls specifies the mode bits for the new object. For instance, when the UNIX touch command is used to create an object, the command usually specifies the user, group, and other mode bits as r and w in the resulting creat( ) system call.

· The value of the UNIX file creation mask of the process that creates the object. The file creation mask filters the mode bits initially assigned to an object; the mask is defined with the UNIX umask command to be the octal complement of the allowable mode bits. For instance, when a user creates an object, the value of the file creation mask of the user's process filters the mode bits assigned to the object.

For a new object, user, group, or other receives a mode bit only if the bit is specified in the system call and the bit is not filtered by the file creation mask. For instance, user for a new object receives read access only if the system call that creates the object specifies the r mode bit for user and the file creation mask of the creating process does not restrict user from having the r mode bit.

For example, the system call to create a new file typically specifies read and write access for user, group, and other; the file creation mask commonly restricts group and other to only read and execute access. When the file is created, user has the r and w bits, while group and other have only the r bit.

Similarly, the system call to create a new directory usually specifies read, write, and execute access for user, group, and other; the file creation mask commonly restricts group and other to only read and execute access. When the directory is created, user has the r, w, and x bits, while group and other have just the r and x bits.

A new directory whose parent directory has no Initial Container Creation ACL is created without an Initial Container Creation ACL. Likewise, a new directory whose parent directory has no Initial Object Creation ACL is created without an Initial Object Creation ACL.

Displaying Implicit (Nonexistent) ACLs

If you use dcecp acl show command to display a nonexistent Object ACL, DCE LFS displays an implicit Object ACL. Although an Object ACL does not physically exist, DCE LFS constructs an implicit Object ACL whose entries and permissions match the object's UNIX mode bits.

For the implicit Object ACL of a directory, DCE LFS expands the w mode bit to grant the i and d ACL permissions in addition to the w permission. Until a directory has an Object ACL, DCE LFS must perform this expansion to allow for the creation of objects in the directory; without the i and d ACL permissions, the directory would effectively be read-only. Once the ACL exists, DCE LFS maps the w mode bit to just the w ACL permission, not the i and d permissions (see ACL Interaction with UNIX Mode Bits ). Because the i and d ACL permissions are meaningless for a file, DCE LFS does not expand the w mode bit on the implicit Object ACL of a file.

If you use the dcecp acl show command to display a nonexistent Initial Creation ACL, DCE LFS displays an implicit Initial Creation ACL. It bases the permissions of the implicit Initial Creation ACL solely on a file creation mask of 0 (zero). In this case, DCE LFS ignores the file creation mask of the process that attempts to display the nonexistent Initial Creation ACL. For the implicit Initial Container Creation ACL, DCE LFS expands the w permission to grant the i and d permissions as well.

Like the user_obj entries of explicit ACLs (which physically exist), the user_obj entries of implicit ACLs grant the c permission. This ensures that the owner of an object can always change the ACLs of the object. Cell administrators for the File Server machine on which an object physically resides can also always change the ACLs of the object.

If you use the dcecp acl show -ic command to display the Initial Container Creation ACL of a directory that does not have this ACL, the command always displays an implicit Initial Container Creation ACL that has the following entries and permissions:

{user_obj rwxcid}

{group_obj rwx-id}

{other_obj rwx-id}

If you use the dcecp acl show -io command to display the Initial Object Creation ACL of a directory that does not have this ACL, the command always displays an implicit Initial Object Creation ACL that has the following entries and permissions:

{user_obj rwxc - }

{group_obj rwx - }

{other_obj rwx - }

Note again that for an object created in a DCE LFS directory that does not have the appropriate Initial Creation ACL, DCE LFS considers the value of the file creation mask of the process that creates the new object when determining the object's initial mode bits. DCE LFS ignores the file creation mask of the calling process only when displaying nonexistent Initial Creation ACLs.

Creating Explicit (Existing) ACLs

The Object ACL and Initial Creation ACLs of an object that is protected only with UNIX mode bits remain implicit until you use the dcecp acl command to save them, at which point DCE LFS creates explicit ACLs for the object. For example, if you use the dcecp acl modify command to change an implicit ACL, DCE LFS creates an explicit ACL when it saves the changes.

Unless you change the permissions with the dcecp acl command that saves the ACL, the permissions granted by an Object ACL created with the command match the object's initial mode bits. Similarly, unless you change them with the dcecp acl command that saves the ACL, the permissions granted by an Initial Creation ACL created with the command are based on a file creation mask of 0 (zero).

Note that an Object ACL is always created for a file or directory created by a foreign user, even if the parent directory does not have the appropriate Initial Creation ACL. Because an unauthenticated user is treated as a user from an unknown foreign cell, an Object ACL is always created for an object created by an unauthenticated user also. The permissions granted by an Object ACL created in this way are based on the UNIX mode bits specified at the system call level when the object is created and the value of the UNIX file creation mask of the creating process.