openafs/doc/xml/AdminGuide/c31274.html

3951 lines
69 KiB
HTML
Raw Normal View History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Managing Access Control Lists</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="AFS Administration Guide"
HREF="book1.html"><LINK
REL="UP"
TITLE="Managing Users and Groups"
HREF="p24911.html"><LINK
REL="PREVIOUS"
TITLE="Administering the Protection Database"
HREF="c29323.html"><LINK
REL="NEXT"
TITLE="Managing Administrative Privilege"
HREF="c32432.html"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>AFS Administration Guide: Version 3.6</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="c29323.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="c32432.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="HDRWQ562"
></A
>Chapter 15. Managing Access Control Lists</H1
><P
>To control access to a directory and all of the files in it, AFS associates an <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>access control list</I
></SPAN
>
(<SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>ACL</I
></SPAN
>) with it, rather than the mode bits that the UNIX file system (UFS) associates with individual files or
directories. AFS ACLs provide more refined access control because there are seven access permissions rather than UFS's three, and
there is room for approximately 20 user or group entries on an ACL, rather than just the three UFS entries (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>owner</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>group</B
></SPAN
>, and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>other</B
></SPAN
>).</P
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ563"
>Summary of Instructions</A
></H1
><P
>This chapter explains how to perform the following tasks by using the indicated commands:</P
><DIV
CLASS="informaltable"
><A
NAME="AEN31285"
></A
><TABLE
BORDER="0"
FRAME="void"
CLASS="CALSTABLE"
><COL
WIDTH="57*"><COL
WIDTH="43*"><TBODY
><TR
><TD
>Examine access control list</TD
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
></TD
></TR
><TR
><TD
>Edit ACL's normal permissions section</TD
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
></TD
></TR
><TR
><TD
>Edit ACL's negative permissions section</TD
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> with <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
> flag</TD
></TR
><TR
><TD
>Replace an ACL</TD
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> with <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
> flag</TD
></TR
><TR
><TD
>Copy an ACL</TD
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs copyacl</B
></SPAN
></TD
></TR
><TR
><TD
>Remove obsolete AFS UIDs</TD
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs cleanacl</B
></SPAN
></TD
></TR
></TBODY
></TABLE
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ565"
>Protecting Data in AFS</A
></H1
><P
>This section describes the main differences between the AFS and UFS file protection systems, discusses the implications of
directory-level protections, and describes the seven access permissions.</P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="HDRWQ566"
>Differences Between UFS and AFS Data Protection</A
></H2
><P
>The UFS mode bits data protection system and the AFS ACL system differ in the following ways: <UL
><LI
><P
>Protection at the file level (UFS) versus the directory level (AFS)</P
><P
>UFS associates a set of nine mode bits with each file element, three (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rwx</B
></SPAN
>) for
each of the element's owner, owning group, and all other users. A similar set of mode bits on the file's directory
applies to the file only in an oblique way.</P
><P
>An AFS ACL instead protects all files in a directory in the same way. If a certain file is more sensitive than
others, store it in a directory with a more restrictive ACL.</P
><P
>Defining access at the directory level has important consequences: <UL
><LI
><P
>The permissions on a directory's ACL apply to all of the files in the directory. When you move a file to a
different directory, you effectively change the access permissions that apply to it to those on its new
directory's ACL. Changing a directory's ACL changes the protection on all the files in it.</P
></LI
><LI
><P
>When you create a subdirectory, its initial ACL is created as a copy of its parent directory's ACL. You can
then change the subdirectory's ACL independently. However, the parent directory's ACL continues to control access
to the subdirectory in the following way: the parent directory's ACL must grant the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permission to a user (or a group the user
belongs to) in order for the user to access the subdirectory at all.</P
><P
>In general, then, it is best to assign fairly liberal access permissions to high-level directories
(including user home directories). In particular, it often makes sense to grant at least the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permission to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> or <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
> group on high-level directories. For further discussion, see <A
HREF="c31274.html#HDRWQ571"
>Using Groups on ACLs</A
>.</P
></LI
></UL
></P
></LI
><LI
><P
>How the mode bits are interpreted</P
><P
>Mode bits are the only file-protection system in UFS. AFS allows you to set the UNIX mode bits on a file in
addition to the ACL on its directory, but it interprets them differently. See <A
HREF="c31274.html#HDRWQ580"
>How AFS
Interprets the UNIX Mode Bits</A
>.</P
></LI
><LI
><P
>Three access permissions (UFS) versus seven (AFS)</P
><P
>UFS defines three access permissions in the form of mode bits: <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>), <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
>), and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>x</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>execute</B
></SPAN
>). AFS defines seven permissions, which makes access
control more precise. For detailed descriptions, see <A
HREF="c31274.html#HDRWQ567"
>The AFS ACL Permissions</A
>.
<TABLE
BORDER="0"
><TBODY
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>)</TD
></TR
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>d</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>delete</B
></SPAN
>)</TD
></TR
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>i</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>insert</B
></SPAN
>)</TD
></TR
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>k</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lock</B
></SPAN
>)</TD
></TR
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>)</TD
></TR
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>)</TD
></TR
><TR
><TD
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
>)</TD
></TR
></TBODY
></TABLE
></P
></LI
><LI
><P
>Three defined users and groups (UFS) versus many (AFS)</P
><P
>UFS controls access for one user and two groups by providing a set of mode bits for each: the user who owns the
file or directory, a single defined group, and everyone who has an account on the system.</P
><P
>AFS, in contrast, allows you to place many entries (individual users or groups) on an ACL, granting a different
set of access permissions to each one. The number of possible entries is about 20, and depends on how much space each
entry occupies in the memory allocated for the ACL itself.</P
><P
>AFS defines two system groups, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
>, which represent all users and all authenticated users, respectively; for further
discussion, see <A
HREF="c31274.html#HDRWQ571"
>Using Groups on ACLs</A
>. In addition, users can define their own groups in
the Protection Database, consisting of individual users or machine IP addresses. Users who have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> permission on an ACL can create entries for the system groups as well as groups defined by
themselves or other users. For information on defining groups, see <A
HREF="c29323.html"
>Administering the Protection
Database</A
>.</P
><P
>When a user requests access to a file or directory, the File Server sums together all of the permissions that the
relevant ACL extends to the user and to groups to which the user belongs. Placing group entries on ACLs therefore can
control access for many more users than the ACL can accommodate as individual entries.</P
></LI
></UL
></P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="HDRWQ567"
>The AFS ACL Permissions</A
></H2
><P
>Functionally, the seven standard ACL permissions fall into two groups: one that applies to the directory itself and one
that applies to the files it contains.</P
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="HDRWQ568"
>The Four Directory Permissions</A
></H3
><P
>The four permissions in this group are meaningful with respect to the directory itself. For example, the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>i</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>insert</B
></SPAN
>) permission does not control addition of data to a file,
but rather creation of a new file or subdirectory. <DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The l (lookup) permission</B
></SPAN
></DT
><DD
><P
>This permission functions as something of a gate keeper for access to the directory and its files, because a
user must have it in order to exercise any other permissions. In particular, a user must have this permission to
access anything in the directory's subdirectories, even if the ACL on a subdirectory grants extensive permissions.
</P
><P
>This permission enables a user to issue the following commands: <UL
><LI
><P
>The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls</B
></SPAN
> command to list the names of the files and subdirectories in the
directory</P
></LI
><LI
><P
>The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -ld</B
></SPAN
> command to obtain complete status information for the
directory element itself</P
></LI
><LI
><P
>The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> command to examine the directory's ACL</P
></LI
></UL
></P
><P
>This permission does not enable a user to read the contents of a file in the directory, to issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -l</B
></SPAN
> command on a file in the directory, or to issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
listacl</B
></SPAN
> command with the filename as the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-path</B
></SPAN
> argument. Those
operations require the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) permission which
is described in <A
HREF="c31274.html#HDRWQ569"
>The Three File Permissions</A
>.</P
><P
>Similarly, this permission does not enable a user to issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -l</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -ld</B
></SPAN
>, or <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
listacl</B
></SPAN
> commands against a subdirectory of the directory. Those operations require the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permission on the ACL of the subdirectory itself.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The i (insert) permission</B
></SPAN
></DT
><DD
><P
>This permission enables a user to add new files to the directory, either by creating or copying, and to create
new subdirectories. It does not extend into any subdirectories, which are protected by their own ACLs. </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The d (delete) permission</B
></SPAN
></DT
><DD
><P
>This permission enables a user to remove files and subdirectories from the directory or move them into other
directories (assuming that the user has the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>i</B
></SPAN
> permission on the ACL of the other
directories). </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The a (administer) permission</B
></SPAN
></DT
><DD
><P
>This permission enables a user to change the directory's ACL. Members of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:administrators</B
></SPAN
> group implicitly have this permission on every directory (that is, even
if that group does not appear on the ACL). Similarly, the owner of a directory implicitly has this permission on its
ACL and those of all directories below it that he or she owns. </P
></DD
></DL
></DIV
></P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="HDRWQ569"
>The Three File Permissions</A
></H3
><P
>The three permissions in this group are meaningful with respect to files in a directory, rather than the directory
itself or its subdirectories. <DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The r (read) permission</B
></SPAN
></DT
><DD
><P
>This permission enables a user to read the contents of files in the directory and to issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -l</B
></SPAN
> command to stat the file elements. </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The w (write) permission</B
></SPAN
></DT
><DD
><P
>This permission enables a user to modify the contents of files in the directory and to issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>chmod</B
></SPAN
> command to change their UNIX mode bits. </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>The k (lock) permission</B
></SPAN
></DT
><DD
><P
>This permission enables the user to run programs that issue system calls to lock files in the directory.
</P
></DD
></DL
></DIV
></P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="Header_635"
>The Eight Auxiliary Permissions</A
></H3
><P
>AFS provides eight additional permissions that do not have a defined meaning, denoted by the uppercase letters
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>A</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>B</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>C</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>D</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>E</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>F</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>G</B
></SPAN
>, and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>H</B
></SPAN
>.</P
><P
>You can write application programs that assign a meaning to one or more of the permissions, and then place them on
ACLs to control file access by those programs. For example, you can modify a print program to recognize and interpret the
permissions, and then place them on directories that house files that the program accesses. Use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
listacl</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> commands to display and set the auxiliary permissions on
ACLs just like the standard seven.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="Header_636"
>Shorthand Notation for Sets of Permissions</A
></H3
><P
>You can combine the seven permissions in any way in an ACL entry, but certain combinations are more useful than
others. Four of the more common combinations have corresponding shorthand forms. When using the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
setacl</B
></SPAN
> command to define ACL entries, you can provide either one or more of the individual letters that represent
the permissions, or one of the following shorthand forms: <DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>all</B
></SPAN
></DT
><DD
><P
>Represents all seven standard permissions (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rlidwka</B
></SPAN
>). </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>none</B
></SPAN
></DT
><DD
><P
>Removes the entry from the ACL, leaving the user or group with no permissions. </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
></DT
><DD
><P
>Represents the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permissions. </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
></DT
><DD
><P
>Represents all permissions except <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>): <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rlidwk</B
></SPAN
>.</P
></DD
></DL
></DIV
></P
></DIV
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="HDRWQ570"
>Using Normal and Negative Permissions</A
></H2
><P
>ACLs enable you both to grant and to deny access to a directory and the files in it. To grant access, use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command to create an ACL entry that associates a set of permissions with a user or group, as
described in <A
HREF="c31274.html#HDRWQ573"
>Setting ACL Entries</A
>. When you use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
>
command to display an ACL (as described in <A
HREF="c31274.html#HDRWQ572"
>Displaying ACLs</A
>), such entries appear underneath
the following header, which uses the term <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>rights</I
></SPAN
> to refer to permissions:</P
><PRE
CLASS="programlisting"
>&#13; Normal rights
</PRE
><P
>There are two ways to deny access: <OL
TYPE="1"
><LI
><P
>The recommended method is simply to omit an entry for the user or group from the ACL, or to omit the appropriate
permissions from the entry. Use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command to remove or edit an existing
entry, using the instructions in <A
HREF="c31274.html#HDRWQ574"
>To add, remove, or edit normal ACL permissions</A
>. In most
circumstances, this method is enough to prevent access of certain kinds or by certain users. You must take care,
however, not to grant the undesired permissions to any groups to which such users belong.</P
></LI
><LI
><P
>The more explicit method for denying access is to use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
> flag to the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command to create an entry that associates <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>negative
permissions</I
></SPAN
> with the user or group; for instructions, see <A
HREF="c31274.html#HDRWQ575"
>To add, remove, or edit
negative ACL permissions</A
>. The output from the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> command lists negative
entries underneath the following header: <PRE
CLASS="programlisting"
>&#13; Negative rights
</PRE
></P
><P
>When determining what type of access to grant to a user, the File Server first compiles a set of permissions by
examining all of the entries in the <SAMP
CLASS="computeroutput"
>Normal rights</SAMP
> section of the ACL. It then subtracts
any permissions associated with the user (or with groups to which the user belongs) on the <SAMP
CLASS="computeroutput"
>Negative
rights</SAMP
> section of the ACL. Therefore, negative permissions always cancel out normal permissions.</P
><P
>Using negative permissions reverses the usual semantics of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command,
introducing the potential for confusion. In particular, combining the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>none</B
></SPAN
> shorthand
and the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
> flag constitutes a double negative: by removing an entry from the
<SAMP
CLASS="computeroutput"
>Negative rights</SAMP
> section of the ACL, you enable a user once again to obtain permissions
via entries in the <SAMP
CLASS="computeroutput"
>Normal rights</SAMP
> section. Combining the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>all</B
></SPAN
> shorthand with the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
> flag explicitly denies all
permissions.</P
><P
>Note also that it is pointless to create an entry in the <SAMP
CLASS="computeroutput"
>Negative rights</SAMP
> section
if an entry in the <SAMP
CLASS="computeroutput"
>Normal rights</SAMP
> section grants the denied permissions to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> group. In this case, users can obtain the permissions simply by using the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>unlog</B
></SPAN
> command to discard their tokens. When they do so, the File Server recognizes them
as the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>anonymous</B
></SPAN
> user, who belongs to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> group but does not match the entries on the <SAMP
CLASS="computeroutput"
>Negative
rights</SAMP
> section of the ACL.</P
></LI
></OL
></P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="HDRWQ571"
>Using Groups on ACLs</A
></H2
><P
>As previously mentioned, placing a group entry on an ACL enables you to control access for many users at once. You can
grant a new user access to many files and directories simply by adding the user to a group that appears on the relevant ACLs.
You can also create groups of machines, in which case any user logged on to the machine obtains the access that is granted to
the group. On directories where they have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> permission on the ACL, users can define their
own groups and can create ACL entries for any groups, not just groups that they create or own themselves. For instructions on
creating groups of users or machines, and a discussion of the most effective ways to use different types of groups, see <A
HREF="c29323.html"
>Administering the Protection Database</A
>. </P
><P
>AFS also defines the following two system groups, which can be very useful on ACLs because they potentially represent a
large group of people. For more information about these groups, see <A
HREF="c29323.html#HDRWQ535"
>The System Groups</A
>.
<DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
></DT
><DD
><P
>Includes anyone who can access the cell's file tree, including users who have logged in as the local superuser
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>root</B
></SPAN
>, have connected to a local machine from somewhere outside the cell, and AFS
users who belong to a foreign cell. This group includes users who do not have tokens that are valid for the local AFS
servers; the servers recognize them as the user <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>anonymous</B
></SPAN
>.</P
><P
>Note that creating an ACL entry for this group is the only way to extend access to AFS users from foreign cells,
unless you create local authentication accounts for them. </P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
></DT
><DD
><P
>Includes all users who have a valid AFS token obtained from the local cell's authentication service.</P
></DD
></DL
></DIV
></P
><P
>It is particularly useful to grant the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>)
permission to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> group on the ACL of most directories in the file system,
especially at the upper levels. This permission enables users only to learn the names of files and subdirectories in a
directory, but without it they cannot traverse their way through the directories in the path to a target file.</P
><P
>A slightly more restrictive alternative is to grant the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permission to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
> group. If that is still not restrictive enough, you can grant the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> to specific users or groups, which cannot exceed about 20 in number on a given ACL.</P
><P
>Another reason to grant certain permissions to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> group is to enable
the correct operation of processes that provide services such as printing and mail delivery. For example, in addition to the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permission, a print process possibly needs the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
>
(<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) permission in order to access the contents of files, and a mail delivery process
possibly requires the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>i</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>insert</B
></SPAN
>) permission to deliver new
pieces of mail.</P
><P
>The ACL on the root directory of every newly created volume grants all permissions to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:administrators</B
></SPAN
> group. You can remove this entry if you wish, but members of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:administrators</B
></SPAN
> group always implicitly have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>), and by default also the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
>, permission on every
directory's ACL. The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> permission enables them to grant themselves other permissions
explicitly when necessary. To learn about changing this default set of permissions, see <A
HREF="c32432.html#HDRWQ586"
>Administering
the system:administrators Group</A
>.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ572"
>Displaying ACLs</A
></H1
><P
>To display the ACL associated with a file, directory or symbolic link, issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
listacl</B
></SPAN
> command. The output for a symbolic link displays the ACL that applies to its target file or directory, rather
than the ACL on the directory that houses the symbolic link.</P
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>Note for AFS/DFS Migration Toolkit users:</B
></SPAN
> If the machine on which you issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit,
you can use the command to display the ACL on DFS files and directories. To display a DFS directory's Initial Container and
Initial Object ACL instead of the regular one, include the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> command's <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-id</B
></SPAN
> or <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-if</B
></SPAN
> flag. For instructions, see the <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>IBM AFS/DFS
Migration Toolkit Administration Guide and Reference</I
></SPAN
>. The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs</B
></SPAN
> command interpreter
ignores the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-id</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-if</B
></SPAN
> flags if you include them when
displaying an AFS ACL. </P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="Header_640"
>To display an ACL</A
></H2
><OL
TYPE="1"
><LI
><P
>Issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> command. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;+]
</PRE
></P
><P
>where</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>la</B
></SPAN
></DT
><DD
><P
>Is an acceptable alias for <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>listacl</B
></SPAN
> (and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lista</B
></SPAN
> is the shortest acceptable abbreviation).</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>dir/file path</B
></SPAN
></DT
><DD
><P
>Names one or more files or directories for which to display the ACL. For files, the output displays the ACL
for its directory. If you omit this argument, the output is for the current working directory. Partial pathnames are
interpreted relative to the current working directory. You can also use the following notation on its own or as part
of a pathname: <DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>.</B
></SPAN
></DT
><DD
><P
>(A single period). Specifies the current working directory.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>..</B
></SPAN
></DT
><DD
><P
>(Two periods). Specifies the current working directory's parent directory.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>*</B
></SPAN
></DT
><DD
><P
>(The asterisk). Specifies each file and subdirectory in the current working directory. The ACL
displayed for a file is always the same as for its directory, but the ACL for each subdirectory can
differ.</P
></DD
></DL
></DIV
></P
></DD
></DL
></DIV
></LI
></OL
><P
>The following error message indicates that you do not have the permissions needed to display an ACL. To specify a
directory name as the dir/file path argument, you must have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permission on the ACL. To specify a filename, you must also have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) permission on its directory's ACL.</P
><PRE
CLASS="programlisting"
>&#13; fs: You don't have the required access permissions on 'dir/file path'
</PRE
><P
>Members of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:administrators</B
></SPAN
> group and the directory's owner (as reported by
the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -ld</B
></SPAN
> command) implicitly have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission on every directory's ACL, and can use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
setacl</B
></SPAN
> command to grant themselves the required permissions; for instructions, see <A
HREF="c31274.html#HDRWQ573"
>Setting
ACL Entries</A
>.</P
><P
>The output for each file or directory specified as dir/file path begins with the following header to identify it:</P
><PRE
CLASS="programlisting"
>&#13; Access list for dir/file path is
</PRE
><P
>The <SAMP
CLASS="computeroutput"
>Normal rights</SAMP
> header appears on the next line, followed by lines that each pair a
user or group name and a set of permissions. The permissions appear as the single letters defined in <A
HREF="c31274.html#HDRWQ567"
>The AFS ACL Permissions</A
>, and always in the order <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rlidwka</B
></SPAN
>. If there
are any negative permissions, the <SAMP
CLASS="computeroutput"
>Negative rights</SAMP
> header appears next, followed by pairs of
negative permissions.</P
><P
>The following example displays the ACL on user <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry</B
></SPAN
>'s home directory in the ABC
Corporation cell:</P
><PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs la /afs/abc.com/usr/terry</B
></SPAN
>
Access list for /afs/abc.com/usr/terry is
Normal permissions:
system:authuser rl
pat rlw
terry rlidwka
Negative permissions:
terry:other-dept rl
jones rl
</PRE
><P
>where <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>pat</B
></SPAN
>, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry</B
></SPAN
>, and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>jones</B
></SPAN
> are individual users, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
> is a system group, and
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry:other-dept</B
></SPAN
> is a group that <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry</B
></SPAN
> owns. The list of
normal permissions grants all permissions to <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry</B
></SPAN
>, the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
>
(<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>), <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>), and
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
>) permissions to <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>pat</B
></SPAN
>, and the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permissions to
the members of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
> group.</P
><P
>The list of negative permissions denies the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
>
permissions to <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>jones</B
></SPAN
> and the members of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry:other-dept</B
></SPAN
>
group. These entries effectively prevent them from accessing <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry</B
></SPAN
>'s home directory in any
way, because they cancel out the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permissions
extended to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
> group, which is the only entry on the <SAMP
CLASS="computeroutput"
>Normal
rights</SAMP
> section of the ACL that possibly applies to them.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ573"
>Setting ACL Entries</A
></H1
><P
>To add, remove, or edit ACL entries, use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command. By default, the command
manipulates entries on the normal permissions section of the ACL. To manipulate entries on the negative permissions section,
include the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
> flag.</P
><P
>You must have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission on an ACL to
edit it. The owner of a directory (as reported by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -ld</B
></SPAN
>) command and members of the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:administrators</B
></SPAN
> group always implicitly have it on every ACL. By default, members of the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:administrators</B
></SPAN
> group also implicitly have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
>
(<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permission.</P
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>Note for AFS/DFS Migration Toolkit users:</B
></SPAN
> If the machine on which you issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit,
you can use the command to set the ACL on DFS files and directories. To set a DFS directory's Initial Container and Initial
Object ACL instead of the regular one, include the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command's <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-id</B
></SPAN
> or <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-if</B
></SPAN
> flag. For instructions, see the <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>IBM AFS/DFS
Migration Toolkit Administration Guide and Reference</I
></SPAN
>. The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs</B
></SPAN
> command interpreter
ignores the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-id</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-if</B
></SPAN
> flags if you include them when setting
an AFS ACL. </P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="HDRWQ574"
>To add, remove, or edit normal ACL permissions</A
></H2
><OL
TYPE="1"
><LI
><P
>Verify that you have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission
on each directory for which you are editing the ACL. If necessary, issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
>
command, which is fully described in <A
HREF="c31274.html#HDRWQ572"
>Displaying ACLs</A
>. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;]
</PRE
></P
></LI
><LI
><P
>Issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command to edit entries in the normal permissions section of
the ACL. To remove an entry, specify the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>none</B
></SPAN
> shorthand as the permissions. If an ACL
entry already exists, the permissions you specify completely replace those in the existing entry. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl -dir</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>directory</VAR
>&#62;+ <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>access list entries</VAR
>&#62;+
</PRE
></P
><P
>where</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>sa</B
></SPAN
></DT
><DD
><P
>Is an acceptable alias for <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>setacl</B
></SPAN
> (and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>seta</B
></SPAN
>
is the shortest acceptable abbreviation).</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
></DT
><DD
><P
>Names one or more directories to which to apply the ACL entries defined by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> argument. Partial pathnames are interpreted relative to the current working
directory.</P
><P
>Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a
read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the
pathname's second level (for example, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>/afs/.abc.com</B
></SPAN
>). For further discussion of the
concept of read/write and read-only paths through the filespace, see <A
HREF="c8420.html#HDRWQ209"
>The Rules of Mount
Point Traversal</A
>.</P
><P
>You can also use the following notation on its own or as part of a pathname:</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>.</B
></SPAN
></DT
><DD
><P
>(A single period). If used by itself, sets the ACL on the current working directory.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>..</B
></SPAN
></DT
><DD
><P
>(Two periods). If used by itself, sets the ACL on the current working directory's parent
directory.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>*</B
></SPAN
></DT
><DD
><P
>(The asterisk). Sets the ACL on each of the subdirectories in the current working directory. You must
precede it with the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
> switch, since it potentially designates multiple
directories. The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs</B
></SPAN
> command interpreter generates the following error message
for each file in the directory: <PRE
CLASS="programlisting"
>&#13; fs: 'filename': Not a directory
</PRE
></P
></DD
></DL
></DIV
><P
>If you specify only one directory or file name, you can omit the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
> and
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> switches.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
></DT
><DD
><P
>Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate
the pairs, and the two parts of each pair, with one or more spaces.</P
><P
>To define the permissions, provide either:</P
><UL
><LI
><P
>One or more of the letters that represent the standard or auxiliary permissions (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rlidwka</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ABCDEFGH</B
></SPAN
>), in any order</P
></LI
><LI
><P
>One of the four shorthand notations: <UL
><LI
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>all</B
></SPAN
> (equals <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rlidwka</B
></SPAN
>)</P
></LI
><LI
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>none</B
></SPAN
> (removes the entry)</P
></LI
><LI
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
> (equals <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rl</B
></SPAN
>)</P
></LI
><LI
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
> (equals <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>rlidwk</B
></SPAN
>)</P
></LI
></UL
></P
></LI
></UL
><P
>For a more detailed description of the permissions and shorthand notations, see <A
HREF="c31274.html#HDRWQ567"
>The
AFS ACL Permissions</A
>.</P
><P
>On a single command line, you can combine user and group entries. You can also use individual letters in some
pairs and the shorthand notations in other pairs, but cannot combine letters and shorthand notation within a single
pair.</P
></DD
></DL
></DIV
></LI
></OL
><P
>Either of the following examples grants user <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>pat</B
></SPAN
> the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
>
(<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>)
permissions on the ACL of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>notes</B
></SPAN
> subdirectory in the issuer's home directory. They
illustrate how it is possible to omit the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
>
switches when you name only one directory.</P
><PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs sa ~/notes pat rl</B
></SPAN
>
% <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs sa ~/notes pat read</B
></SPAN
>
</PRE
><P
>The following example edits the ACL for the current working directory. It removes the entry for the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:anyuser</B
></SPAN
> group, and adds two entries: one grants all permissions except <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) to the members of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry:colleagues</B
></SPAN
> group and the other grants the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permissions to
the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>system:authuser</B
></SPAN
> group. The command appears on two lines here only for legibility.</P
><PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs sa -dir . -acl system:anyuser none terry:colleagues write \
system:authuser rl</B
></SPAN
>
</PRE
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="HDRWQ575"
>To add, remove, or edit negative ACL permissions</A
></H2
><OL
TYPE="1"
><LI
><P
>Verify that you have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission
on each directory for which you are editing the ACL. If necessary, issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
>
command, which is fully described in <A
HREF="c31274.html#HDRWQ572"
>Displaying ACLs</A
>. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;]
</PRE
></P
></LI
><LI
><P
>Issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command with the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
>
flag to edit entries in the negative permissions section of the ACL. To remove an entry, specify the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>none</B
></SPAN
> shorthand as the permissions. If an ACL entry already exists for a user or group, the
permissions you specify completely replace those in the existing entry. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl -dir</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>directory</VAR
>&#62;+ <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>access list entries</VAR
>&#62;+ <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
>
</PRE
></P
><P
>where</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>sa</B
></SPAN
></DT
><DD
><P
>Is an acceptable alias for <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>setacl</B
></SPAN
> (and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>seta</B
></SPAN
>
is the shortest acceptable abbreviation).</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
></DT
><DD
><P
>Names one or more directories to which to apply the negative ACL entries defined by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> argument. Specify the read/write path to each directory, to avoid the failure that
results when you attempt to change a read-only volume. For a detailed description of acceptable values, see <A
HREF="c31274.html#HDRWQ574"
>To add, remove, or edit normal ACL permissions</A
>.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
></DT
><DD
><P
>Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate
the pairs, and the two parts of each pair, with one or more spaces. For a detailed description of acceptable values,
see <A
HREF="c31274.html#HDRWQ574"
>To add, remove, or edit normal ACL permissions</A
>. Keep in mind that the usual
meaning of each permission is reversed.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
></DT
><DD
><P
>Places the entries defined by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> argument on the negative permissions
section of the ACL for each directory named by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
> argument.</P
></DD
></DL
></DIV
></LI
></OL
><P
>The following example denies user <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>pat</B
></SPAN
> the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
>) and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>d</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>delete</B
></SPAN
>) permissions for
the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>project</B
></SPAN
> subdirectory of the current working directory.</P
><PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs sa project pat wd -neg</B
></SPAN
>
</PRE
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ576"
>Completely Replacing an ACL</A
></H1
><P
>It is sometimes simplest to clear an ACL completely before defining new permissions on it, for instance if the mix of
normal and negative permissions makes it difficult to understand how their interaction affects a user's access to the directory.
To clear an ACL completely while you define new entries, include the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
> flag on the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command. When you include this flag, you can create entries on either the normal
permissions or the negative permissions section of the ACL, but not on both at once.</P
><P
>Remember to create an entry that grants appropriate permissions to the directory's owner. The owner implicitly has the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission required to replace a deleted entry,
but the effects of a missing ACL entry (particularly the lack of the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
> permission) can be
so confusing that it becomes difficult for the owner to realize that the missing entry is causing the problems. </P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="Header_645"
>To replace an ACL completely</A
></H2
><OL
TYPE="1"
><LI
><P
>Verify that you have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission
on each directory for which you are editing the ACL. If necessary, issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
>
command, which is fully described in <A
HREF="c31274.html#HDRWQ572"
>Displaying ACLs</A
>. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;]
</PRE
></P
></LI
><LI
><P
>Issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl</B
></SPAN
> command with the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
> flag
to clear the ACL completely before setting either normal or negative permissions. Because you need to grant the owner of
the directory all permissions, it is better in most cases to set normal permissions at this point. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs setacl -dir</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>directory</VAR
>&#62;+ <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>access list entries</VAR
>&#62;+ <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
> \
[<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
>]
</PRE
></P
><P
>where</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>sa</B
></SPAN
></DT
><DD
><P
>Is an acceptable alias for <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>setacl</B
></SPAN
> (and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>seta</B
></SPAN
>
is the shortest acceptable abbreviation).</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-dir</B
></SPAN
></DT
><DD
><P
>Names one or more directories to which to apply the negative ACL entries defined by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> argument. Specify the read/write path to each directory, to avoid the failure that
results when you attempt to change a read-only volume. For a detailed description of acceptable values, see <A
HREF="c31274.html#HDRWQ574"
>To add, remove, or edit normal ACL permissions</A
>.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
></DT
><DD
><P
>Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate
the pairs, and the two parts of each pair, with one or more spaces. Remember to grant all permissions to the owner
of the directory. For a detailed description of acceptable values, see <A
HREF="c31274.html#HDRWQ574"
>To add, remove, or
edit normal ACL permissions</A
>.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
></DT
><DD
><P
>Removes all entries from each ACL before creating the entries indicated by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> argument.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-negative</B
></SPAN
></DT
><DD
><P
>Places the entries defined by the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-acl</B
></SPAN
> argument on the negative permissions
section of each ACL.</P
></DD
></DL
></DIV
></LI
></OL
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ577"
>Copying ACLs Between Directories</A
></H1
><P
>The <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs copyacl</B
></SPAN
> command copies a source directory's ACL to one or more destination
directories. It does not affect the source ACL at all, but changes each destination ACL as follows: <UL
><LI
><P
>If an entry on the source ACL does not exist on the destination ACL, the command copies it to the destination
ACL.</P
></LI
><LI
><P
>If an entry on the destination ACL does not also exist on the source ACL, the command does not remove it unless you
include the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
> flag to overwrite the destination ACL completely.</P
></LI
><LI
><P
>If an entry is on both ACLs, the command changes the permissions on the destination ACL entry to match the source
ACL entry.</P
></LI
></UL
></P
><P
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>Note for AFS/DFS Migration Toolkit users:</B
></SPAN
> If the machine is configured to enable AFS
users to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, then you can use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs
copyacl</B
></SPAN
> command to copy ACLs between DFS files and directories also. The command includes <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-id</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-if</B
></SPAN
> flags for altering a DFS directory's Initial Container and
Initial Object ACLs as well as its regular ACL; see the <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>IBM AFS/DFS Migration Toolkit Administration Guide and
Reference</I
></SPAN
>. You cannot copy ACLs between AFS and DFS directories, because they use different ACL formats. The
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs</B
></SPAN
> command interpreter ignores the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-id</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-if</B
></SPAN
> flags if you include them when copying AFS ACLs. </P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="Header_647"
>To copy an ACL between directories</A
></H2
><OL
TYPE="1"
><LI
><P
>Verify that you have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permission on
the source ACL and the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission on each
destination ACL. To identify the source directory by naming a file in it, you must also have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) permission on the source ACL. If necessary, issue the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> command, which is fully described in <A
HREF="c31274.html#HDRWQ572"
>Displaying
ACLs</A
>. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;]
</PRE
></P
></LI
><LI
><P
><A
NAME="LIWQ578"
></A
>Issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs copyacl</B
></SPAN
> command to copy a source ACL to the ACL
on one or more destination directories. (The command appears here on two lines only for legibility.) <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs copyacl -fromdir</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>source directory</VAR
>&#62; <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-todir</B
></SPAN
> &#60;<VAR
CLASS="replaceable"
>destination directory</VAR
>&#62;+ \
[<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
>]
</PRE
></P
><P
>where</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>co</B
></SPAN
></DT
><DD
><P
>Is the shortest acceptable abbreviation for <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>copyacl</B
></SPAN
>.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-fromdir</B
></SPAN
></DT
><DD
><P
>Names the source directory from which to copy the ACL. Partial pathnames are interpreted relative to the
current working directory. If this argument names a file, the ACL is copied from its directory.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-todir</B
></SPAN
></DT
><DD
><P
>Names each destination directory to which to copy the source ACL. Partial pathnames are interpreted relative
to the current working directory. Filenames are not acceptable.</P
><P
>Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a
read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the
pathname's second level (for example, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>/afs/.abc.com</B
></SPAN
>). For further discussion of the
concept of read/write and read-only paths through the filespace, see <A
HREF="c8420.html#HDRWQ209"
>The Rules of Mount
Point Traversal</A
>.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
></DT
><DD
><P
>Completely overwrites each destination directory's ACL with the source ACL.</P
></DD
></DL
></DIV
></LI
></OL
><P
>The following example copies the ACL from the current working directory's <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>notes</B
></SPAN
>
subdirectory to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>plans</B
></SPAN
> subdirectory. The issuer does not include the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-clear</B
></SPAN
> flag, so the entry for user <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>pat</B
></SPAN
> remains on the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>plans</B
></SPAN
> directory's ACL although there is no corresponding entry on the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>notes</B
></SPAN
> directory's ACL.</P
><PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs la notes plans</B
></SPAN
>
Access list for notes is
Normal permissions:
terry rlidwka
smith rl
jones rl
Access list for plans is
Normal permissions:
terry rlidwk
pat rlidwk
% <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs copyacl notes plans</B
></SPAN
>
% <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs la notes plans</B
></SPAN
>
Access list for notes is
Normal permissions:
terry rlidwka
smith rl
jones rl
Access list for plans is
Normal permissions:
terry rlidwka
pat rlidwk
smith rl
jones rl
</PRE
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ579"
>Removing Obsolete AFS IDs from ACLs</A
></H1
><P
>When you remove a user or group entry from the Protection Database, the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
>
command displays the user's AFS UID (or group's AFS GID) in ACL entries, rather than the name. In the following example, user
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry</B
></SPAN
> has an ACL entry for the group <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>terry:friends</B
></SPAN
> (AFS GID
-567) on her home directory in the ABC Corporation cell, and then removes the group from the Protection Database.</P
><PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl /afs/abc.com/usr/terry</B
></SPAN
>
Access list for /afs/abc.com/usr/terry is
Normal permissions:
terry:friends rlik
system:anyuser l
terry rlidwka
% <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>pts delete terry:friends</B
></SPAN
>
% <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl /afs/abc.com/usr/terry</B
></SPAN
>
Access list for /afs/abc.com/usr/terry is
Normal permissions:
-567 rlik
system:anyuser l
terry rlidwka
</PRE
><P
>Leaving AFS IDs on ACLs serves no function, because the ID no longer corresponds to an active user or group. Furthermore,
if the ID is ever assigned to a new user or group, then the new possessor of the ID gains access that the owner of the directory
actually intended for the previous possessor. (Reusing AFS IDs is not recommended precisely for this reason.)</P
><P
>To remove obsolete AFS UIDs from ACLs, use the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs cleanacl</B
></SPAN
> command. </P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="Header_649"
>To clean obsolete AFS IDs from an ACL</A
></H2
><OL
TYPE="1"
><LI
><P
>Verify that you have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>a</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>administer</B
></SPAN
>) permission
on each directory for which you are cleaning the ACL. If necessary, issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
>
command, which is fully described in <A
HREF="c31274.html#HDRWQ572"
>Displaying ACLs</A
>. <PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs listacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;]
</PRE
></P
></LI
><LI
><P
>Issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs cleanacl</B
></SPAN
> command to remove entries for obsolete AFS IDs.
<PRE
CLASS="programlisting"
>&#13; % <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>fs cleanacl</B
></SPAN
> [&#60;<VAR
CLASS="replaceable"
>dir/file path</VAR
>&#62;+]
</PRE
></P
><P
>where</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>cl</B
></SPAN
></DT
><DD
><P
>Is the shortest acceptable abbreviation of <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>cleanacl</B
></SPAN
>.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>dir/file path</B
></SPAN
></DT
><DD
><P
>Names each directory for which to clean the ACL. If this argument names a file, its directory's ACL is
cleaned. Omit this argument to clean the current working directory's ACL.</P
><P
>Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a
read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the
pathname's second level (for example, <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>/afs/.abc.com</B
></SPAN
>). For further discussion of the
concept of read/write and read-only paths through the filespace, see <A
HREF="c8420.html#HDRWQ209"
>The Rules of Mount
Point Traversal</A
>.</P
><P
>You can also use the following notation on its own or as part of a pathname:</P
><DIV
CLASS="variablelist"
><DL
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>.</B
></SPAN
></DT
><DD
><P
>(A single period). If used by itself, cleans the current working directory's ACL.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>..</B
></SPAN
></DT
><DD
><P
>(Two periods). If used by itself, cleans the ACL on the current working directory's parent
directory.</P
></DD
><DT
><SPAN
CLASS="bold"
><B
CLASS="emphasis"
>*</B
></SPAN
></DT
><DD
><P
>(The asterisk). Cleans the ACL of each of the subdirectories in the current working directory. However,
if you use the asterisk and there are obsolete AFS IDs on any directory's ACL, the following error message
appears for every file in the directory: <PRE
CLASS="programlisting"
>&#13; fs: 'filename': Not a directory
</PRE
></P
></DD
></DL
></DIV
></DD
></DL
></DIV
></LI
></OL
><P
>If there are obsolete AFS IDs on a directory, the command interpreter displays its cleaned ACL under the following
header.</P
><PRE
CLASS="programlisting"
>&#13; Access list for directory is now
</PRE
><P
>If a directory's ACL has no obsolete AFS IDs on it, the following message appears for each.</P
><PRE
CLASS="programlisting"
>&#13; Access list for directory is fine.
</PRE
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="HDRWQ580"
>How AFS Interprets the UNIX Mode Bits</A
></H1
><P
>Although AFS uses ACLs to protect file data rather than the mode bits that UFS uses, it does not ignore the mode bits
entirely. When you issue the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>chmod</B
></SPAN
> command on an AFS file or directory, AFS changes the bits
appropriately. To change a file's mode bits, you must have the AFS <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>write</B
></SPAN
>) permission on the ACL of the file's directory. To change a directory's mode bits, you must have
the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>d</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>delete</B
></SPAN
>), <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>i</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>insert</B
></SPAN
>), and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>lookup</B
></SPAN
>) permissions on
its ACL.</P
><P
>AFS also uses the UNIX mode bits as follows:</P
><UL
><LI
><P
>It uses the initial bit to determine the element's type. This is the bit that appears first in the output from the
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>ls -l</B
></SPAN
> command and shows the hyphen (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>-</B
></SPAN
>) for a file or the
letter <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>d</B
></SPAN
> for a directory.</P
></LI
><LI
><P
>It does not use any of the mode bits on a directory.</P
></LI
><LI
><P
>For a file, the first (owner) set of bits interacts with the ACL entries that apply to the file in the following way:
<UL
><LI
><P
>If the first <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> mode bit is not set, no one (including the owner) can read the
file, no matter what permissions they have on the ACL. If the bit is set, users also need the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> (<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>read</B
></SPAN
>) and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permissions on
the ACL of the file's directory to read the file.</P
></LI
><LI
><P
>If the first <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> mode bit is not set, no one (including the owner) can modify the
file. If the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> bit is set, users also need the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>w</B
></SPAN
> and
<SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permissions on the ACL of the file's directory to modify the file.</P
></LI
><LI
><P
>There is no ACL permission directly corresponding to the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>x</B
></SPAN
> mode bit, but to
execute a file stored in AFS, the user must also have the <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>r</B
></SPAN
> and <SPAN
CLASS="bold"
><B
CLASS="emphasis"
>l</B
></SPAN
> permissions on the ACL of the file's directory.</P
></LI
></UL
></P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="c29323.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="c32432.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Administering the Protection Database</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="p24911.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Managing Administrative Privilege</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>