Guides for

• New Students
• Students
• Faculty
• Staff
• IT Staff

Search the UBIT site

Questions and comments about this should be sent to: cit-webmaster@buffalo.edu
Privacy Accessibility Statement
Last updated:
Copyright © 2006
All Rights Reserved.

Documentation

UBFS Files and Directories - Controlling Access with DCECP

Introduction

This document focuses on the DCECP (UNIX Distributed Computing Environment Control Program) ACL command interface. If you are not familiar with UNIX, we strongly recommend that you use the web interface WebACL. For more information on WebACL, see the CIT document UBFS Files and Directories - Controlling Access with WebACL.

What Is UBFS?

The University at Buffalo File System (UBFS) is a centrally located disk resource that you have access to from wherever you connect to the UB computer system. The UBFS directory hierarchy is configured like a tree. The root (or beginning) of the tree is indicated by /ubfs. Your personal disk area is located in a subdirectory at the following position:
ubfs/user/u/s/username/ub

u and s are the first two letters of your UBITName, and username is your UBITName itself. You are the owner of all subdirectories under /ubfs/user/u/s/username/ub, including nt, solaris, public_html, and data. The system owns all directories above, including ub. Anyone with a valid UBITName can access these directories. For more information on UBFS, see the CIT document UBFS, or visit http://ubit.buffalo.edu/ubfs.

Accessing UBFS

ACLs are available for the UBFS file space only. To access UBFS from UNIX, log into your UBUnix account and type:
cd $UBFSHOME

If you are not authenticated by the Distributed Computing Environment (DCE) server, you may get an error message similar to Permission denied. If this happens, type the following:
dce_login

You will be asked to enter a Principal Name and Password (your UBITName and Password, respectively). Once you enter this information, you will receive access to your UBFS space.

What Are ACLs?

Access to files and directories (folders) in UBFS is controlled through access control lists (ACLs), which describe the access granted to a list of users and groups. Groups are lists of users. These lists are created by system administrators. Because you are the owner of all subdirectories under your personal disk area, you have full access control over them. You can view and modify ACL settings with the DCECP ACL command interface on UBUnix.

Objects and Permissions

Files and directories are both classified as objects within the ACL paradigm. Each ACL entry for an object includes a set of permissions that define the operations that a user or group can perform on the object. An entry has the following format:
{type [key] permissions}

type specifies the kind of user or group to which the permissions apply, and key indicates the specific user or group. The following types are available:

There is a special type (mask_obj) that specifies the maximum set of permissions a user or a group may have. Permissions applied to entries other than user_obj and other_obj are filtered through mask_obj. This means that the access of a specific user or group is determined by the intersection of the mask_obj entry and the specific user or group entry. For more information on the mask_obj entry, see the subsection The mask_obj Entry.

The following table lists the ACL permissions for directories:

The following table lists the ACL permissions for files:

Displaying ACL Permissions

To display ACL permissions on an object, type the following from your UBUnix prompt:
dcecp -c acl show object_name

object_name is the name of the object for which you wish to display ACL permissions. You can run DCECP in either interactive or command line mode. In the example above, -c is the command line mode option, and acl show is the command for displaying ACLs.

Assuming mydir is a directory that belongs to user msmith, typing dcecp -c acl show mydir will result in a display similar to the following:
{mask_obj rwxcid}
{user_obj rwxcid}
{user msmith rwxcid}
{user cell_admin rwxcid
{user janedoe r-----}[
{group_obj ------}
{other_obj ------}

In this example, owner msmith has two entries: user_obj and user msmith. Sometimes an owner may have only one entry (user_obj). If an owner has more than one entry, the owner's access rights are always determined by the user_obj entry. In this case, msmith has full access to mydir, while the specific user janedoe has read access.

In this example, neither group_obj nor other_obj have any access. The group_obj entry refers to the object's owning group (the primary group to which the owner belongs). You can find the name of the group by using ls -lg, and you can change group ownership by using the UNIX command chgrp. For more information on UNIX commands, see the CIT document Introduction to UNIX.

Setting ACL Permissions

To modify ACL settings, run DCECP interactively by typing dcecp at the UNIX prompt. The DCECP prompt looks like this:
dcecp>

The general syntax for an ACL command is:
command object_name -options
{type key permission}

object_name is the name of the file or directory you wish to change, and command is one of the following commands:

Some commands require options. The options for acl modify are:

Assuming mydir is a directory, you can modify ACLs using the modify options, as shown below. User and group require a key; group_obj does not.

dcecp> acl modify mydir -add {user jdoe rx}
dcecp> acl modify mydir -add {group myclass rx}
dcecp> acl modify mydir -change {group_obj rx}
dcecp> acl modify mydir -remove {user janedoe}
dcecp> acl show mydir
{mask_obj rwxcid}
{user_obj rwxcid}
{user msmith rwxcid}
{user cell_admin rwxcid}
{user jdoe r-x---}
{group_obj r-x---}
{group myclass r-x---}
{other_obj ------}
dcecp> acl check mydir
rwxcid

In this example, owner msmith added user jdoe and group myclass, and removed the user janedoe, all of which require a key. The group_obj does not require a key.

For more information on the permissions necessary to perform operations on files and directories, see the section Appendix: ACL Permissions.

The mask_obj Entry

Special attention must be given to the mask_obj entry. It should always remain set to {mask_obj rwxcid}. As previously noted, the mask_obj entry behaves like an access filter. Permissions applied to any other ACL entries, except those for user_obj and other_obj, are filtered through mask_obj. In other words, the access a specific user or group may have is determined by the intersection of the mask_obj entry and the specific user or group entry. If both entries agree on a permission, the permission exists for the specific entry. If the entries disagree however, the permission is not granted. The resulting permissions appear as an effective entry next to the main (pre-set) ACL entries.

As an example, consider the following set of permissions:
{mask_obj ---cid}
{user_obj rwxcid}
{user msmith rwxcid effective ---cid}
{user cell_admin rwxcid effect ---cid}
{user jdoe r-x--- effective ------}
{group_obj r-x--- effective ------}
{group myclass r-x--- effective ------}
{other_obj ------}

In this example, because mask_obj is set to ---cid, user jdoe and group myclass have no access, even though their pre-set ACLs show that they have the read and execute permissions.

To eliminate the discrepancy between effective and pre-set permissions, type the following from the DCECP prompt:
acl modify mydir -change {mask_obj rwxcid}

The mask_obj entry is now set to allow full permissions, and the effective entries disappear. As a result, the actual permissions become the same as the pre-set permissions shown in the example.

Only one user entry can exist for a given username, so an acl modify command with the -add option fails if the user to be added already appears on the ACL.

Permissions given to an entry with the acl modify command and the -change option replace the existing permissions associated with the entry. However, specified permissions are not added to the existing permissions. If you would like a user or group to retain permissions already granted, you must include the old permissions with the acl modify command. For example, if jdoe already has read (r) and execute (x) permissions and you wish to add the write (w) permission to the entry, you would use the following command:
acl modify mydir -change {user jdoe rwx}

ACL Evaluation

To determine a user's access rights for an object, the entries on the object's ACL are evaluated in order of the following sequence:

1. The user owns the object, in which case the user's access rights are determined by the user_obj entry.
2. A user entry exists for the user, in which case the user's access rights are the intersection of the user entry (e.g., {user jdoe r-x---}) and the mask_obj entry (e.g., {mask_obj rwxcid}).
3. The user belongs to either the group that owns the object, specified by the groub_obj entry, or to another group with group entries for the object. In this case, the user's access rights are the union of entries of all applicable groups, filtered by the mask_obj entry. For example, if the user jdoe does not have a user entry but belongs to the myclass group, then user jdoe will have the same rights as the myclass group.
4. The user is a member of the UB Intranet (i.e., the user has a valid UBITName). In this case, the user's access rights are determined by the other_obj entry.
5. The user matches no entry, in which case the user cannot access the object.

The evaluation process stops as soon as the user matches a condition in the list. Evaluation proceeds to the next condition only if the user fails to match all of the previous conditions.

It is possible to grant access to an entire group while excluding specific members. For example, if user jdoe belongs to the group myclass, the following ACL ensures that everyone in the group myclass has desired access except the user jdoe:
{mask_obj rwxcid}
{user_obj rwxcid}
{user msmith rwxcid}
{user cell_admin rwxcid}
{user jdoe ------}
{group_obj r-x---}
{group myclass r-x---}
{other_obj ------}

ACLs and UNIX Mode Bits

In the UNIX Network File System (NFS), every object is associated with a set of mode bits that define the permissions granted to the three types of users: the owner, the owning group, and all other system users. These types are known as user, group, and other, respectively.

Each type of user can receive any combination of the r, w, and x permissions via the appropriate mode bits. The operations associated with the bits are similar to those associated with the UBFS ACL. You can view the mode bits for an object by using the UNIX command ls -l, and set them with the command chmod.

Because ACLs are only used for objects in UBFS space, mode bits are the only form of protection associated with objects in most non-UBFS file spaces, including your home directory. In UBFS space, all files and directory objects have both UNIX mode bits and ACLs. A user's access rights in UBFS space, however, are dictated by ACLs.

To synchronize the protections set by an object's UNIX mode bits and those set by its ACL, symmetry between the two is maintained as follows:

1. The user mode bits are identified with the r, w, and x permissions of the user_obj entry.
2. The group mode bits are identified with the r, w, and x permissions of the mask_obj entry. If the mask_obj entry does not exist, the group mode bits are identified with the r, w, and x permissions of the group_obj entry.
3. The other mode bits are identified with the r, w, and x permissions of the other_obj entry.

Note that there are no mode bits associated with the control (c), insert (i), and delete (d) permissions.

To maintain this correspondence, UBFS updates the matching UNIX mode bits each time you modify the permissions associated with a user_obj, mask_obj, or other_obj entry.

For example, suppose that mysubdir is a subdirectory with the following ACL entries:
{mask_obj rwxcid}
{user_obj rwxcid}
{group_obj ------}
{other_obj ------}

The mode bits as displayed by the UNIX command ls -lg would appear as follows:
drwxrwx--- 1   msmith myclass    3625 nov 22
11:36 mysubdir 

Similarly, if you use chmod to modify the mode bits associated with an object, ACL entries will change accordingly. Thus, the mode bits and the ACL permissions of an object will agree.

To ensure proper protections for your files and directories, it is recommended that you not use the UNIX chmod command in the UBFS space. If you use the chmod command to grant permissions to a group, the permissions will translate to the ACL mask_obj entry, not to the group_obj entry, since mask_obj exists by default in the UBFS file space. If you want to grant access rights to the owning group, make sure that the mask_obj entry is set to rwxcid, and then use the DCECP command acl modify to set the desired permissions on group_obj. For example, to grant the owning group read (r) and execute (x) rights, type the following from your DCECP prompt:
acl modify mysubdir -change {group_obj rx}

Initial ACL Settings for New Files and Directories

Every directory has two additional ACLs: an initial file ACL and an initial directory ACL. The initial file ACL is known as the Initial Object ACL, or io, and the initial directory ACL is known as the Initial Container ACL, or ic. These default settings determine ACLs on new files and subdirectories created in the directory.

To display or modify a directory's io or ic ACL, include the -io or -ic options with the DCECP commands acl show or acl modify:
dcecp> acl show mydir -io
dcecp> acl show mydir -ic

If you need to grant a particular user access to some of your files, you may want to create a directory to hold these files, and then add the user to the directory's initial files ACL. The user will retain the granted access for any new file created in the directory.

Shared Area ACLs

UBFS has a designated "shared area" that individuals can use to share files with others. The term "shared" in this context means that two or more people have write access to the same files and directories. The shared area is located within the /ubfs/shared/ub directory hierarchy. When a shared area is created, the directory ACL, initial file ACL, and initial directory ACL should contain entries for each specific user or specific group that needs shared access to the directory.

For example, suppose user jdoe has a shared area located at /ubfs/shared/ub/jdoe and wants to share it with the specific user msmith and the specific group myclass. To ensure that these entities have the intended access to both the directory itself and any new files or directories created within it, entries for the specific user msmith and the specific group myclass should be present in the following ACLs:

• The ACL of the directory /ubfs/shared/ub/jdoe. This ensures appropriate access to the directory itself.
• The Initial Object ACL for /ubfs/shared/ub/jdoe. This ensures appropriate access to any new files created within the directory.
• The Initial Container ACL for /ubfs/shared/ub/jdoe. This ensures the appropriate access to any new subdirectories created within the directory.

Careful attention to initial file and directory ACLs ensures that the file system grows with the desired access controls.

Appendix: ACL Permissions

In the following table, an object refers to a file or directory. The search permission for a directory is interpreted as the execute permission for a file.

Document Information