1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
5 >Managing Access Control Lists</TITLE
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
10 TITLE="AFS Administration Guide"
11 HREF="book1.html"><LINK
13 TITLE="Managing Users and Groups"
14 HREF="p24911.html"><LINK
16 TITLE="Administering the Protection Database"
17 HREF="c29323.html"><LINK
19 TITLE="Managing Administrative Privilege"
20 HREF="c32432.html"></HEAD
31 SUMMARY="Header navigation table"
40 >AFS Administration Guide: Version 3.6</TH
77 >Chapter 15. Managing Access Control Lists</H1
79 >To control access to a directory and all of the files in it, AFS associates an <SPAN
83 >access control list</I
92 >) with it, rather than the mode bits that the UNIX file system (UFS) associates with individual files or
93 directories. AFS ACLs provide more refined access control because there are seven access permissions rather than UFS's three, and
94 there is room for approximately 20 user or group entries on an ACL, rather than just the three UFS entries (<SPAN
119 >Summary of Instructions</A
122 >This chapter explains how to perform the following tasks by using the indicated commands:</P
124 CLASS="informaltable"
137 >Examine access control list</TD
149 >Edit ACL's normal permissions section</TD
161 >Edit ACL's negative permissions section</TD
209 >Remove obsolete AFS UIDs</TD
229 >Protecting Data in AFS</A
232 >This section describes the main differences between the AFS and UFS file protection systems, discusses the implications of
233 directory-level protections, and describes the seven access permissions.</P
240 >Differences Between UFS and AFS Data Protection</A
243 >The UFS mode bits data protection system and the AFS ACL system differ in the following ways: <UL
246 >Protection at the file level (UFS) versus the directory level (AFS)</P
248 >UFS associates a set of nine mode bits with each file element, three (<SPAN
255 each of the element's owner, owning group, and all other users. A similar set of mode bits on the file's directory
256 applies to the file only in an oblique way.</P
258 >An AFS ACL instead protects all files in a directory in the same way. If a certain file is more sensitive than
259 others, store it in a directory with a more restrictive ACL.</P
261 >Defining access at the directory level has important consequences: <UL
264 >The permissions on a directory's ACL apply to all of the files in the directory. When you move a file to a
265 different directory, you effectively change the access permissions that apply to it to those on its new
266 directory's ACL. Changing a directory's ACL changes the protection on all the files in it.</P
270 >When you create a subdirectory, its initial ACL is created as a copy of its parent directory's ACL. You can
271 then change the subdirectory's ACL independently. However, the parent directory's ACL continues to control access
272 to the subdirectory in the following way: the parent directory's ACL must grant the <SPAN
284 >) permission to a user (or a group the user
285 belongs to) in order for the user to access the subdirectory at all.</P
287 >In general, then, it is best to assign fairly liberal access permissions to high-level directories
288 (including user home directories). In particular, it often makes sense to grant at least the <SPAN
294 > permission to the <SPAN
306 > group on high-level directories. For further discussion, see <A
307 HREF="c31274.html#HDRWQ571"
308 >Using Groups on ACLs</A
316 >How the mode bits are interpreted</P
318 >Mode bits are the only file-protection system in UFS. AFS allows you to set the UNIX mode bits on a file in
319 addition to the ACL on its directory, but it interprets them differently. See <A
320 HREF="c31274.html#HDRWQ580"
322 Interprets the UNIX Mode Bits</A
327 >Three access permissions (UFS) versus seven (AFS)</P
329 >UFS defines three access permissions in the form of mode bits: <SPAN
365 >). AFS defines seven permissions, which makes access
366 control more precise. For detailed descriptions, see <A
367 HREF="c31274.html#HDRWQ567"
368 >The AFS ACL Permissions</A
491 >Three defined users and groups (UFS) versus many (AFS)</P
493 >UFS controls access for one user and two groups by providing a set of mode bits for each: the user who owns the
494 file or directory, a single defined group, and everyone who has an account on the system.</P
496 >AFS, in contrast, allows you to place many entries (individual users or groups) on an ACL, granting a different
497 set of access permissions to each one. The number of possible entries is about 20, and depends on how much space each
498 entry occupies in the memory allocated for the ACL itself.</P
500 >AFS defines two system groups, <SPAN
512 >, which represent all users and all authenticated users, respectively; for further
514 HREF="c31274.html#HDRWQ571"
515 >Using Groups on ACLs</A
516 >. In addition, users can define their own groups in
517 the Protection Database, consisting of individual users or machine IP addresses. Users who have the <SPAN
523 > permission on an ACL can create entries for the system groups as well as groups defined by
524 themselves or other users. For information on defining groups, see <A
526 >Administering the Protection
530 >When a user requests access to a file or directory, the File Server sums together all of the permissions that the
531 relevant ACL extends to the user and to groups to which the user belongs. Placing group entries on ACLs therefore can
532 control access for many more users than the ACL can accommodate as individual entries.</P
543 >The AFS ACL Permissions</A
546 >Functionally, the seven standard ACL permissions fall into two groups: one that applies to the directory itself and one
547 that applies to the files it contains.</P
554 >The Four Directory Permissions</A
557 >The four permissions in this group are meaningful with respect to the directory itself. For example, the <SPAN
569 >) permission does not control addition of data to a file,
570 but rather creation of a new file or subdirectory. <DIV
578 >The l (lookup) permission</B
583 >This permission functions as something of a gate keeper for access to the directory and its files, because a
584 user must have it in order to exercise any other permissions. In particular, a user must have this permission to
585 access anything in the directory's subdirectories, even if the ACL on a subdirectory grants extensive permissions.
588 >This permission enables a user to issue the following commands: <UL
597 > command to list the names of the files and subdirectories in the
608 > command to obtain complete status information for the
609 directory element itself</P
619 > command to examine the directory's ACL</P
624 >This permission does not enable a user to read the contents of a file in the directory, to issue the <SPAN
630 > command on a file in the directory, or to issue the <SPAN
637 > command with the filename as the <SPAN
644 operations require the <SPAN
658 HREF="c31274.html#HDRWQ569"
659 >The Three File Permissions</A
662 >Similarly, this permission does not enable a user to issue the <SPAN
687 > commands against a subdirectory of the directory. Those operations require the <SPAN
693 > permission on the ACL of the subdirectory itself.</P
700 >The i (insert) permission</B
705 >This permission enables a user to add new files to the directory, either by creating or copying, and to create
706 new subdirectories. It does not extend into any subdirectories, which are protected by their own ACLs. </P
713 >The d (delete) permission</B
718 >This permission enables a user to remove files and subdirectories from the directory or move them into other
719 directories (assuming that the user has the <SPAN
725 > permission on the ACL of the other
733 >The a (administer) permission</B
738 >This permission enables a user to change the directory's ACL. Members of the <SPAN
742 >system:administrators</B
744 > group implicitly have this permission on every directory (that is, even
745 if that group does not appear on the ACL). Similarly, the owner of a directory implicitly has this permission on its
746 ACL and those of all directories below it that he or she owns. </P
758 >The Three File Permissions</A
761 >The three permissions in this group are meaningful with respect to files in a directory, rather than the directory
762 itself or its subdirectories. <DIV
770 >The r (read) permission</B
775 >This permission enables a user to read the contents of files in the directory and to issue the <SPAN
781 > command to stat the file elements. </P
788 >The w (write) permission</B
793 >This permission enables a user to modify the contents of files in the directory and to issue the <SPAN
799 > command to change their UNIX mode bits. </P
806 >The k (lock) permission</B
811 >This permission enables the user to run programs that issue system calls to lock files in the directory.
824 >The Eight Auxiliary Permissions</A
827 >AFS provides eight additional permissions that do not have a defined meaning, denoted by the uppercase letters
878 >You can write application programs that assign a meaning to one or more of the permissions, and then place them on
879 ACLs to control file access by those programs. For example, you can modify a print program to recognize and interpret the
880 permissions, and then place them on directories that house files that the program accesses. Use the <SPAN
893 > commands to display and set the auxiliary permissions on
894 ACLs just like the standard seven.</P
902 >Shorthand Notation for Sets of Permissions</A
905 >You can combine the seven permissions in any way in an ACL entry, but certain combinations are more useful than
906 others. Four of the more common combinations have corresponding shorthand forms. When using the <SPAN
913 > command to define ACL entries, you can provide either one or more of the individual letters that represent
914 the permissions, or one of the following shorthand forms: <DIV
927 >Represents all seven standard permissions (<SPAN
945 >Removes the entry from the ACL, leaving the user or group with no permissions. </P
957 >Represents the <SPAN
993 >Represents all permissions except <SPAN
1024 >Using Normal and Negative Permissions</A
1027 >ACLs enable you both to grant and to deny access to a directory and the files in it. To grant access, use the <SPAN
1033 > command to create an ACL entry that associates a set of permissions with a user or group, as
1035 HREF="c31274.html#HDRWQ573"
1036 >Setting ACL Entries</A
1037 >. When you use the <SPAN
1044 command to display an ACL (as described in <A
1045 HREF="c31274.html#HDRWQ572"
1047 >), such entries appear underneath
1048 the following header, which uses the term <SPAN
1054 > to refer to permissions:</P
1056 CLASS="programlisting"
1057 > Normal rights
1060 >There are two ways to deny access: <OL
1064 >The recommended method is simply to omit an entry for the user or group from the ACL, or to omit the appropriate
1065 permissions from the entry. Use the <SPAN
1071 > command to remove or edit an existing
1072 entry, using the instructions in <A
1073 HREF="c31274.html#HDRWQ574"
1074 >To add, remove, or edit normal ACL permissions</A
1076 circumstances, this method is enough to prevent access of certain kinds or by certain users. You must take care,
1077 however, not to grant the undesired permissions to any groups to which such users belong.</P
1081 >The more explicit method for denying access is to use the <SPAN
1094 > command to create an entry that associates <SPAN
1101 > with the user or group; for instructions, see <A
1102 HREF="c31274.html#HDRWQ575"
1103 >To add, remove, or edit
1104 negative ACL permissions</A
1105 >. The output from the <SPAN
1111 > command lists negative
1112 entries underneath the following header: <PRE
1113 CLASS="programlisting"
1114 > Negative rights
1118 >When determining what type of access to grant to a user, the File Server first compiles a set of permissions by
1119 examining all of the entries in the <SAMP
1120 CLASS="computeroutput"
1121 >Normal rights</SAMP
1122 > section of the ACL. It then subtracts
1123 any permissions associated with the user (or with groups to which the user belongs) on the <SAMP
1124 CLASS="computeroutput"
1127 > section of the ACL. Therefore, negative permissions always cancel out normal permissions.</P
1129 >Using negative permissions reverses the usual semantics of the <SPAN
1136 introducing the potential for confusion. In particular, combining the <SPAN
1149 > flag constitutes a double negative: by removing an entry from the
1151 CLASS="computeroutput"
1152 >Negative rights</SAMP
1153 > section of the ACL, you enable a user once again to obtain permissions
1154 via entries in the <SAMP
1155 CLASS="computeroutput"
1156 >Normal rights</SAMP
1157 > section. Combining the <SPAN
1163 > shorthand with the <SPAN
1169 > flag explicitly denies all
1172 >Note also that it is pointless to create an entry in the <SAMP
1173 CLASS="computeroutput"
1174 >Negative rights</SAMP
1176 if an entry in the <SAMP
1177 CLASS="computeroutput"
1178 >Normal rights</SAMP
1179 > section grants the denied permissions to the <SPAN
1185 > group. In this case, users can obtain the permissions simply by using the
1192 > command to discard their tokens. When they do so, the File Server recognizes them
1199 > user, who belongs to the <SPAN
1205 > group but does not match the entries on the <SAMP
1206 CLASS="computeroutput"
1209 > section of the ACL.</P
1220 >Using Groups on ACLs</A
1223 >As previously mentioned, placing a group entry on an ACL enables you to control access for many users at once. You can
1224 grant a new user access to many files and directories simply by adding the user to a group that appears on the relevant ACLs.
1225 You can also create groups of machines, in which case any user logged on to the machine obtains the access that is granted to
1226 the group. On directories where they have the <SPAN
1232 > permission on the ACL, users can define their
1233 own groups and can create ACL entries for any groups, not just groups that they create or own themselves. For instructions on
1234 creating groups of users or machines, and a discussion of the most effective ways to use different types of groups, see <A
1236 >Administering the Protection Database</A
1239 >AFS also defines the following two system groups, which can be very useful on ACLs because they potentially represent a
1240 large group of people. For more information about these groups, see <A
1241 HREF="c29323.html#HDRWQ535"
1242 >The System Groups</A
1245 CLASS="variablelist"
1257 >Includes anyone who can access the cell's file tree, including users who have logged in as the local superuser
1264 >, have connected to a local machine from somewhere outside the cell, and AFS
1265 users who belong to a foreign cell. This group includes users who do not have tokens that are valid for the local AFS
1266 servers; the servers recognize them as the user <SPAN
1274 >Note that creating an ACL entry for this group is the only way to extend access to AFS users from foreign cells,
1275 unless you create local authentication accounts for them. </P
1287 >Includes all users who have a valid AFS token obtained from the local cell's authentication service.</P
1293 >It is particularly useful to grant the <SPAN
1306 permission to the <SPAN
1312 > group on the ACL of most directories in the file system,
1313 especially at the upper levels. This permission enables users only to learn the names of files and subdirectories in a
1314 directory, but without it they cannot traverse their way through the directories in the path to a target file.</P
1316 >A slightly more restrictive alternative is to grant the <SPAN
1322 > permission to the <SPAN
1328 > group. If that is still not restrictive enough, you can grant the <SPAN
1334 > to specific users or groups, which cannot exceed about 20 in number on a given ACL.</P
1336 >Another reason to grant certain permissions to the <SPAN
1342 > group is to enable
1343 the correct operation of processes that provide services such as printing and mail delivery. For example, in addition to the
1350 > permission, a print process possibly needs the <SPAN
1363 >) permission in order to access the contents of files, and a mail delivery process
1364 possibly requires the <SPAN
1376 >) permission to deliver new
1379 >The ACL on the root directory of every newly created volume grants all permissions to the <SPAN
1383 >system:administrators</B
1385 > group. You can remove this entry if you wish, but members of the <SPAN
1389 >system:administrators</B
1391 > group always implicitly have the <SPAN
1403 >), and by default also the <SPAN
1409 >, permission on every
1410 directory's ACL. The <SPAN
1416 > permission enables them to grant themselves other permissions
1417 explicitly when necessary. To learn about changing this default set of permissions, see <A
1418 HREF="c32432.html#HDRWQ586"
1420 the system:administrators Group</A
1433 >To display the ACL associated with a file, directory or symbolic link, issue the <SPAN
1440 > command. The output for a symbolic link displays the ACL that applies to its target file or directory, rather
1441 than the ACL on the directory that houses the symbolic link.</P
1447 >Note for AFS/DFS Migration Toolkit users:</B
1449 > If the machine on which you issue the <SPAN
1455 > command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit,
1456 you can use the command to display the ACL on DFS files and directories. To display a DFS directory's Initial Container and
1457 Initial Object ACL instead of the regular one, include the <SPAN
1475 > flag. For instructions, see the <SPAN
1480 Migration Toolkit Administration Guide and Reference</I
1488 > command interpreter
1501 > flags if you include them when
1502 displaying an AFS ACL. </P
1509 >To display an ACL</A
1522 CLASS="programlisting"
1538 CLASS="variablelist"
1550 >Is an acceptable alias for <SPAN
1562 > is the shortest acceptable abbreviation).</P
1574 >Names one or more files or directories for which to display the ACL. For files, the output displays the ACL
1575 for its directory. If you omit this argument, the output is for the current working directory. Partial pathnames are
1576 interpreted relative to the current working directory. You can also use the following notation on its own or as part
1578 CLASS="variablelist"
1590 >(A single period). Specifies the current working directory.</P
1602 >(Two periods). Specifies the current working directory's parent directory.</P
1614 >(The asterisk). Specifies each file and subdirectory in the current working directory. The ACL
1615 displayed for a file is always the same as for its directory, but the ACL for each subdirectory can
1627 >The following error message indicates that you do not have the permissions needed to display an ACL. To specify a
1628 directory name as the dir/file path argument, you must have the <SPAN
1640 >) permission on the ACL. To specify a filename, you must also have the <SPAN
1652 >) permission on its directory's ACL.</P
1654 CLASS="programlisting"
1655 > fs: You don't have the required access permissions on 'dir/file path'
1658 >Members of the <SPAN
1662 >system:administrators</B
1664 > group and the directory's owner (as reported by
1671 > command) implicitly have the <SPAN
1683 >) permission on every directory's ACL, and can use the <SPAN
1690 > command to grant themselves the required permissions; for instructions, see <A
1691 HREF="c31274.html#HDRWQ573"
1696 >The output for each file or directory specified as dir/file path begins with the following header to identify it:</P
1698 CLASS="programlisting"
1699 > Access list for dir/file path is
1703 CLASS="computeroutput"
1704 >Normal rights</SAMP
1705 > header appears on the next line, followed by lines that each pair a
1706 user or group name and a set of permissions. The permissions appear as the single letters defined in <A
1707 HREF="c31274.html#HDRWQ567"
1708 >The AFS ACL Permissions</A
1709 >, and always in the order <SPAN
1716 are any negative permissions, the <SAMP
1717 CLASS="computeroutput"
1718 >Negative rights</SAMP
1719 > header appears next, followed by pairs of
1720 negative permissions.</P
1722 >The following example displays the ACL on user <SPAN
1728 >'s home directory in the ABC
1729 Corporation cell:</P
1731 CLASS="programlisting"
1736 >fs la /afs/abc.com/usr/terry</B
1739 Access list for /afs/abc.com/usr/terry is
1744 Negative permissions:
1767 > are individual users, <SPAN
1773 > is a system group, and
1778 >terry:other-dept</B
1780 > is a group that <SPAN
1787 normal permissions grants all permissions to <SPAN
1831 >) permissions to <SPAN
1850 the members of the <SPAN
1858 >The list of negative permissions denies the <SPAN
1871 permissions to <SPAN
1877 > and the members of the <SPAN
1881 >terry:other-dept</B
1884 group. These entries effectively prevent them from accessing <SPAN
1890 >'s home directory in any
1891 way, because they cancel out the <SPAN
1904 extended to the <SPAN
1910 > group, which is the only entry on the <SAMP
1911 CLASS="computeroutput"
1914 > section of the ACL that possibly applies to them.</P
1923 >Setting ACL Entries</A
1926 >To add, remove, or edit ACL entries, use the <SPAN
1932 > command. By default, the command
1933 manipulates entries on the normal permissions section of the ACL. To manipulate entries on the negative permissions section,
1942 >You must have the <SPAN
1954 >) permission on an ACL to
1955 edit it. The owner of a directory (as reported by the <SPAN
1961 >) command and members of the
1966 >system:administrators</B
1968 > group always implicitly have it on every ACL. By default, members of the
1973 >system:administrators</B
1975 > group also implicitly have the <SPAN
1994 >Note for AFS/DFS Migration Toolkit users:</B
1996 > If the machine on which you issue the <SPAN
2002 > command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit,
2003 you can use the command to set the ACL on DFS files and directories. To set a DFS directory's Initial Container and Initial
2004 Object ACL instead of the regular one, include the <SPAN
2022 > flag. For instructions, see the <SPAN
2027 Migration Toolkit Administration Guide and Reference</I
2035 > command interpreter
2048 > flags if you include them when setting
2056 >To add, remove, or edit normal ACL permissions</A
2062 >Verify that you have the <SPAN
2075 on each directory for which you are editing the ACL. If necessary, issue the <SPAN
2082 command, which is fully described in <A
2083 HREF="c31274.html#HDRWQ572"
2086 CLASS="programlisting"
2108 > command to edit entries in the normal permissions section of
2109 the ACL. To remove an entry, specify the <SPAN
2115 > shorthand as the permissions. If an ACL
2116 entry already exists, the permissions you specify completely replace those in the existing entry. <PRE
2117 CLASS="programlisting"
2135 >access list entries</VAR
2142 CLASS="variablelist"
2154 >Is an acceptable alias for <SPAN
2167 is the shortest acceptable abbreviation).</P
2179 >Names one or more directories to which to apply the ACL entries defined by the <SPAN
2185 > argument. Partial pathnames are interpreted relative to the current working
2188 >Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a
2189 read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the
2190 pathname's second level (for example, <SPAN
2196 >). For further discussion of the
2197 concept of read/write and read-only paths through the filespace, see <A
2198 HREF="c8420.html#HDRWQ209"
2203 >You can also use the following notation on its own or as part of a pathname:</P
2205 CLASS="variablelist"
2217 >(A single period). If used by itself, sets the ACL on the current working directory.</P
2229 >(Two periods). If used by itself, sets the ACL on the current working directory's parent
2242 >(The asterisk). Sets the ACL on each of the subdirectories in the current working directory. You must
2243 precede it with the <SPAN
2249 > switch, since it potentially designates multiple
2250 directories. The <SPAN
2256 > command interpreter generates the following error message
2257 for each file in the directory: <PRE
2258 CLASS="programlisting"
2259 > fs: 'filename': Not a directory
2266 >If you specify only one directory or file name, you can omit the <SPAN
2291 >Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate
2292 the pairs, and the two parts of each pair, with one or more spaces.</P
2294 >To define the permissions, provide either:</P
2298 >One or more of the letters that represent the standard or auxiliary permissions (<SPAN
2314 >One of the four shorthand notations: <UL
2339 > (removes the entry)</P
2378 >For a more detailed description of the permissions and shorthand notations, see <A
2379 HREF="c31274.html#HDRWQ567"
2381 AFS ACL Permissions</A
2384 >On a single command line, you can combine user and group entries. You can also use individual letters in some
2385 pairs and the shorthand notations in other pairs, but cannot combine letters and shorthand notation within a single
2393 >Either of the following examples grants user <SPAN
2425 permissions on the ACL of the <SPAN
2431 > subdirectory in the issuer's home directory. They
2432 illustrate how it is possible to omit the <SPAN
2445 switches when you name only one directory.</P
2447 CLASS="programlisting"
2452 >fs sa ~/notes pat rl</B
2459 >fs sa ~/notes pat read</B
2464 >The following example edits the ACL for the current working directory. It removes the entry for the <SPAN
2470 > group, and adds two entries: one grants all permissions except <SPAN
2482 >) to the members of the <SPAN
2486 >terry:colleagues</B
2488 > group and the other grants the <SPAN
2519 > group. The command appears on two lines here only for legibility.</P
2521 CLASS="programlisting"
2526 >fs sa -dir . -acl system:anyuser none terry:colleagues write \
2527 system:authuser rl</B
2538 >To add, remove, or edit negative ACL permissions</A
2544 >Verify that you have the <SPAN
2557 on each directory for which you are editing the ACL. If necessary, issue the <SPAN
2564 command, which is fully described in <A
2565 HREF="c31274.html#HDRWQ572"
2568 CLASS="programlisting"
2590 > command with the <SPAN
2597 flag to edit entries in the negative permissions section of the ACL. To remove an entry, specify the <SPAN
2603 > shorthand as the permissions. If an ACL entry already exists for a user or group, the
2604 permissions you specify completely replace those in the existing entry. <PRE
2605 CLASS="programlisting"
2623 >access list entries</VAR
2636 CLASS="variablelist"
2648 >Is an acceptable alias for <SPAN
2661 is the shortest acceptable abbreviation).</P
2673 >Names one or more directories to which to apply the negative ACL entries defined by the <SPAN
2679 > argument. Specify the read/write path to each directory, to avoid the failure that
2680 results when you attempt to change a read-only volume. For a detailed description of acceptable values, see <A
2681 HREF="c31274.html#HDRWQ574"
2682 >To add, remove, or edit normal ACL permissions</A
2695 >Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate
2696 the pairs, and the two parts of each pair, with one or more spaces. For a detailed description of acceptable values,
2698 HREF="c31274.html#HDRWQ574"
2699 >To add, remove, or edit normal ACL permissions</A
2700 >. Keep in mind that the usual
2701 meaning of each permission is reversed.</P
2713 >Places the entries defined by the <SPAN
2719 > argument on the negative permissions
2720 section of the ACL for each directory named by the <SPAN
2733 >The following example denies user <SPAN
2770 > subdirectory of the current working directory.</P
2772 CLASS="programlisting"
2777 >fs sa project pat wd -neg</B
2789 >Completely Replacing an ACL</A
2792 >It is sometimes simplest to clear an ACL completely before defining new permissions on it, for instance if the mix of
2793 normal and negative permissions makes it difficult to understand how their interaction affects a user's access to the directory.
2794 To clear an ACL completely while you define new entries, include the <SPAN
2807 > command. When you include this flag, you can create entries on either the normal
2808 permissions or the negative permissions section of the ACL, but not on both at once.</P
2810 >Remember to create an entry that grants appropriate permissions to the directory's owner. The owner implicitly has the
2823 >) permission required to replace a deleted entry,
2824 but the effects of a missing ACL entry (particularly the lack of the <SPAN
2830 > permission) can be
2831 so confusing that it becomes difficult for the owner to realize that the missing entry is causing the problems. </P
2838 >To replace an ACL completely</A
2844 >Verify that you have the <SPAN
2857 on each directory for which you are editing the ACL. If necessary, issue the <SPAN
2864 command, which is fully described in <A
2865 HREF="c31274.html#HDRWQ572"
2868 CLASS="programlisting"
2890 > command with the <SPAN
2897 to clear the ACL completely before setting either normal or negative permissions. Because you need to grant the owner of
2898 the directory all permissions, it is better in most cases to set normal permissions at this point. <PRE
2899 CLASS="programlisting"
2917 >access list entries</VAR
2937 CLASS="variablelist"
2949 >Is an acceptable alias for <SPAN
2962 is the shortest acceptable abbreviation).</P
2974 >Names one or more directories to which to apply the negative ACL entries defined by the <SPAN
2980 > argument. Specify the read/write path to each directory, to avoid the failure that
2981 results when you attempt to change a read-only volume. For a detailed description of acceptable values, see <A
2982 HREF="c31274.html#HDRWQ574"
2983 >To add, remove, or edit normal ACL permissions</A
2996 >Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate
2997 the pairs, and the two parts of each pair, with one or more spaces. Remember to grant all permissions to the owner
2998 of the directory. For a detailed description of acceptable values, see <A
2999 HREF="c31274.html#HDRWQ574"
3001 edit normal ACL permissions</A
3014 >Removes all entries from each ACL before creating the entries indicated by the <SPAN
3032 >Places the entries defined by the <SPAN
3038 > argument on the negative permissions
3039 section of each ACL.</P
3053 >Copying ACLs Between Directories</A
3062 > command copies a source directory's ACL to one or more destination
3063 directories. It does not affect the source ACL at all, but changes each destination ACL as follows: <UL
3066 >If an entry on the source ACL does not exist on the destination ACL, the command copies it to the destination
3071 >If an entry on the destination ACL does not also exist on the source ACL, the command does not remove it unless you
3078 > flag to overwrite the destination ACL completely.</P
3082 >If an entry is on both ACLs, the command changes the permissions on the destination ACL entry to match the source
3092 >Note for AFS/DFS Migration Toolkit users:</B
3094 > If the machine is configured to enable AFS
3095 users to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, then you can use the <SPAN
3102 > command to copy ACLs between DFS files and directories also. The command includes <SPAN
3114 > flags for altering a DFS directory's Initial Container and
3115 Initial Object ACLs as well as its regular ACL; see the <SPAN
3119 >IBM AFS/DFS Migration Toolkit Administration Guide and
3122 >. You cannot copy ACLs between AFS and DFS directories, because they use different ACL formats. The
3129 > command interpreter ignores the <SPAN
3141 > flags if you include them when copying AFS ACLs. </P
3148 >To copy an ACL between directories</A
3154 >Verify that you have the <SPAN
3167 the source ACL and the <SPAN
3179 >) permission on each
3180 destination ACL. To identify the source directory by naming a file in it, you must also have the <SPAN
3192 >) permission on the source ACL. If necessary, issue the
3199 > command, which is fully described in <A
3200 HREF="c31274.html#HDRWQ572"
3204 CLASS="programlisting"
3229 > command to copy a source ACL to the ACL
3230 on one or more destination directories. (The command appears here on two lines only for legibility.) <PRE
3231 CLASS="programlisting"
3236 >fs copyacl -fromdir</B
3240 >source directory</VAR
3249 >destination directory</VAR
3263 CLASS="variablelist"
3275 >Is the shortest acceptable abbreviation for <SPAN
3293 >Names the source directory from which to copy the ACL. Partial pathnames are interpreted relative to the
3294 current working directory. If this argument names a file, the ACL is copied from its directory.</P
3306 >Names each destination directory to which to copy the source ACL. Partial pathnames are interpreted relative
3307 to the current working directory. Filenames are not acceptable.</P
3309 >Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a
3310 read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the
3311 pathname's second level (for example, <SPAN
3317 >). For further discussion of the
3318 concept of read/write and read-only paths through the filespace, see <A
3319 HREF="c8420.html#HDRWQ209"
3334 >Completely overwrites each destination directory's ACL with the source ACL.</P
3341 >The following example copies the ACL from the current working directory's <SPAN
3348 subdirectory to the <SPAN
3354 > subdirectory. The issuer does not include the <SPAN
3360 > flag, so the entry for user <SPAN
3366 > remains on the <SPAN
3372 > directory's ACL although there is no corresponding entry on the <SPAN
3378 > directory's ACL.</P
3380 CLASS="programlisting"
3385 >fs la notes plans</B
3388 Access list for notes is
3393 Access list for plans is
3401 >fs copyacl notes plans</B
3408 >fs la notes plans</B
3411 Access list for notes is
3416 Access list for plans is
3431 >Removing Obsolete AFS IDs from ACLs</A
3434 >When you remove a user or group entry from the Protection Database, the <SPAN
3441 command displays the user's AFS UID (or group's AFS GID) in ACL entries, rather than the name. In the following example, user
3448 > has an ACL entry for the group <SPAN
3455 -567) on her home directory in the ABC Corporation cell, and then removes the group from the Protection Database.</P
3457 CLASS="programlisting"
3462 >fs listacl /afs/abc.com/usr/terry</B
3465 Access list for /afs/abc.com/usr/terry is
3474 >pts delete terry:friends</B
3481 >fs listacl /afs/abc.com/usr/terry</B
3484 Access list for /afs/abc.com/usr/terry is
3491 >Leaving AFS IDs on ACLs serves no function, because the ID no longer corresponds to an active user or group. Furthermore,
3492 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
3493 actually intended for the previous possessor. (Reusing AFS IDs is not recommended precisely for this reason.)</P
3495 >To remove obsolete AFS UIDs from ACLs, use the <SPAN
3508 >To clean obsolete AFS IDs from an ACL</A
3514 >Verify that you have the <SPAN
3527 on each directory for which you are cleaning the ACL. If necessary, issue the <SPAN
3534 command, which is fully described in <A
3535 HREF="c31274.html#HDRWQ572"
3538 CLASS="programlisting"
3560 > command to remove entries for obsolete AFS IDs.
3562 CLASS="programlisting"
3578 CLASS="variablelist"
3590 >Is the shortest acceptable abbreviation of <SPAN
3608 >Names each directory for which to clean the ACL. If this argument names a file, its directory's ACL is
3609 cleaned. Omit this argument to clean the current working directory's ACL.</P
3611 >Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a
3612 read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the
3613 pathname's second level (for example, <SPAN
3619 >). For further discussion of the
3620 concept of read/write and read-only paths through the filespace, see <A
3621 HREF="c8420.html#HDRWQ209"
3626 >You can also use the following notation on its own or as part of a pathname:</P
3628 CLASS="variablelist"
3640 >(A single period). If used by itself, cleans the current working directory's ACL.</P
3652 >(Two periods). If used by itself, cleans the ACL on the current working directory's parent
3665 >(The asterisk). Cleans the ACL of each of the subdirectories in the current working directory. However,
3666 if you use the asterisk and there are obsolete AFS IDs on any directory's ACL, the following error message
3667 appears for every file in the directory: <PRE
3668 CLASS="programlisting"
3669 > fs: 'filename': Not a directory
3681 >If there are obsolete AFS IDs on a directory, the command interpreter displays its cleaned ACL under the following
3684 CLASS="programlisting"
3685 > Access list for directory is now
3688 >If a directory's ACL has no obsolete AFS IDs on it, the following message appears for each.</P
3690 CLASS="programlisting"
3691 > Access list for directory is fine.
3701 >How AFS Interprets the UNIX Mode Bits</A
3704 >Although AFS uses ACLs to protect file data rather than the mode bits that UFS uses, it does not ignore the mode bits
3705 entirely. When you issue the <SPAN
3711 > command on an AFS file or directory, AFS changes the bits
3712 appropriately. To change a file's mode bits, you must have the AFS <SPAN
3724 >) permission on the ACL of the file's directory. To change a directory's mode bits, you must have
3764 >AFS also uses the UNIX mode bits as follows:</P
3768 >It uses the initial bit to determine the element's type. This is the bit that appears first in the output from the
3775 > command and shows the hyphen (<SPAN
3781 >) for a file or the
3788 > for a directory.</P
3792 >It does not use any of the mode bits on a directory.</P
3796 >For a file, the first (owner) set of bits interacts with the ACL entries that apply to the file in the following way:
3806 > mode bit is not set, no one (including the owner) can read the
3807 file, no matter what permissions they have on the ACL. If the bit is set, users also need the <SPAN
3826 the ACL of the file's directory to read the file.</P
3836 > mode bit is not set, no one (including the owner) can modify the
3843 > bit is set, users also need the <SPAN
3856 > permissions on the ACL of the file's directory to modify the file.</P
3860 >There is no ACL permission directly corresponding to the <SPAN
3867 execute a file stored in AFS, the user must also have the <SPAN
3879 > permissions on the ACL of the file's directory.</P
3892 SUMMARY="Footer navigation table"
3931 >Administering the Protection Database</TD
3945 >Managing Administrative Privilege</TD
git://git.openafs.org / openafs.git / blob