Commit | Line | Data |
---|---|---|
805e021f CE |
1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | <chapter id="HDRWQ562"> | |
3 | <title>Managing Access Control Lists</title> | |
4 | ||
5 | <para>To control access to a directory and all of the files in it, AFS associates an <emphasis>access control list</emphasis> | |
6 | (<emphasis>ACL</emphasis>) with it, rather than the mode bits that the UNIX file system (UFS) associates with individual files or | |
7 | directories. AFS ACLs provide more refined access control because there are seven access permissions rather than UFS's three, and | |
8 | there is room for approximately 20 user or group entries on an ACL, rather than just the three UFS entries (<emphasis | |
9 | role="bold">owner</emphasis>, <emphasis role="bold">group</emphasis>, and <emphasis role="bold">other</emphasis>).</para> | |
10 | ||
11 | <sect1 id="HDRWQ563"> | |
12 | <title>Summary of Instructions</title> | |
13 | ||
14 | <para>This chapter explains how to perform the following tasks by using the indicated commands:</para> | |
15 | ||
16 | <informaltable frame="none"> | |
17 | <tgroup cols="2"> | |
18 | <colspec colwidth="57*" /> | |
19 | ||
20 | <colspec colwidth="43*" /> | |
21 | ||
22 | <tbody> | |
23 | <row> | |
24 | <entry>Examine access control list</entry> | |
25 | ||
26 | <entry><emphasis role="bold">fs listacl</emphasis></entry> | |
27 | </row> | |
28 | ||
29 | <row> | |
30 | <entry>Edit ACL's normal permissions section</entry> | |
31 | ||
32 | <entry><emphasis role="bold">fs setacl</emphasis></entry> | |
33 | </row> | |
34 | ||
35 | <row> | |
36 | <entry>Edit ACL's negative permissions section</entry> | |
37 | ||
38 | <entry><emphasis role="bold">fs setacl</emphasis> with <emphasis role="bold">-negative</emphasis> flag</entry> | |
39 | </row> | |
40 | ||
41 | <row> | |
42 | <entry>Replace an ACL</entry> | |
43 | ||
44 | <entry><emphasis role="bold">fs setacl</emphasis> with <emphasis role="bold">-clear</emphasis> flag</entry> | |
45 | </row> | |
46 | ||
47 | <row> | |
48 | <entry>Copy an ACL</entry> | |
49 | ||
50 | <entry><emphasis role="bold">fs copyacl</emphasis></entry> | |
51 | </row> | |
52 | ||
53 | <row> | |
54 | <entry>Remove obsolete AFS UIDs</entry> | |
55 | ||
56 | <entry><emphasis role="bold">fs cleanacl</emphasis></entry> | |
57 | </row> | |
58 | </tbody> | |
59 | </tgroup> | |
60 | </informaltable> | |
61 | </sect1> | |
62 | ||
63 | <sect1 id="HDRWQ565"> | |
64 | <title>Protecting Data in AFS</title> | |
65 | ||
66 | <indexterm> | |
67 | <primary>protection of file data</primary> | |
68 | ||
69 | <secondary>see also: <emphasis>ACL</emphasis></secondary> | |
70 | </indexterm> | |
71 | ||
72 | <indexterm> | |
73 | <primary>protection of file data</primary> | |
74 | ||
75 | <secondary>AFS compared to UFS<emphasis>ACL</emphasis></secondary> | |
76 | </indexterm> | |
77 | ||
78 | <para>This section describes the main differences between the AFS and UFS file protection systems, discusses the implications of | |
79 | directory-level protections, and describes the seven access permissions.</para> | |
80 | ||
81 | <sect2 id="HDRWQ566"> | |
82 | <title>Differences Between UFS and AFS Data Protection</title> | |
83 | ||
84 | <indexterm> | |
85 | <primary>UFS</primary> | |
86 | ||
87 | <secondary>file protection compared to AFS</secondary> | |
88 | </indexterm> | |
89 | ||
90 | <indexterm> | |
91 | <primary>protection of file data</primary> | |
92 | ||
93 | <secondary>AFS compared to UFS<emphasis>ACL</emphasis></secondary> | |
94 | </indexterm> | |
95 | ||
96 | <indexterm> | |
97 | <primary>ACL</primary> | |
98 | ||
99 | <secondary>compared to UNIX protection</secondary> | |
100 | </indexterm> | |
101 | ||
102 | <para>The UFS mode bits data protection system and the AFS ACL system differ in the following ways: <itemizedlist> | |
103 | <listitem> | |
104 | <para>Protection at the file level (UFS) versus the directory level (AFS)</para> | |
105 | ||
106 | <para>UFS associates a set of nine mode bits with each file element, three (<emphasis role="bold">rwx</emphasis>) for | |
107 | each of the element's owner, owning group, and all other users. A similar set of mode bits on the file's directory | |
108 | applies to the file only in an oblique way.</para> | |
109 | ||
110 | <para>An AFS ACL instead protects all files in a directory in the same way. If a certain file is more sensitive than | |
111 | others, store it in a directory with a more restrictive ACL.</para> | |
112 | ||
113 | <para>Defining access at the directory level has important consequences: <indexterm> | |
114 | <primary>directory-level data protection</primary> | |
115 | ||
116 | <secondary>implications</secondary> | |
117 | </indexterm> <itemizedlist> | |
118 | <listitem> | |
119 | <para>The permissions on a directory's ACL apply to all of the files in the directory. When you move a file to a | |
120 | different directory, you effectively change the access permissions that apply to it to those on its new | |
121 | directory's ACL. Changing a directory's ACL changes the protection on all the files in it.</para> | |
122 | </listitem> | |
123 | ||
124 | <listitem> | |
125 | <para>When you create a subdirectory, its initial ACL is created as a copy of its parent directory's ACL. You can | |
126 | then change the subdirectory's ACL independently. However, the parent directory's ACL continues to control access | |
127 | to the subdirectory in the following way: the parent directory's ACL must grant the <emphasis | |
128 | role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) permission to a user (or a group the user | |
129 | belongs to) in order for the user to access the subdirectory at all.</para> | |
130 | ||
131 | <para>In general, then, it is best to assign fairly liberal access permissions to high-level directories | |
132 | (including user home directories). In particular, it often makes sense to grant at least the <emphasis | |
133 | role="bold">l</emphasis> permission to the <emphasis role="bold">system:anyuser</emphasis> or <emphasis | |
134 | role="bold">system:authuser</emphasis> group on high-level directories. For further discussion, see <link | |
135 | linkend="HDRWQ571">Using Groups on ACLs</link>.</para> | |
136 | </listitem> | |
137 | </itemizedlist></para> | |
138 | </listitem> | |
139 | ||
140 | <listitem> | |
141 | <para>How the mode bits are interpreted</para> | |
142 | ||
143 | <para>Mode bits are the only file-protection system in UFS. AFS allows you to set the UNIX mode bits on a file in | |
144 | addition to the ACL on its directory, but it interprets them differently. See <link linkend="HDRWQ580">How AFS | |
145 | Interprets the UNIX Mode Bits</link>.</para> | |
146 | </listitem> | |
147 | ||
148 | <listitem> | |
149 | <para>Three access permissions (UFS) versus seven (AFS)</para> | |
150 | ||
151 | <para>UFS defines three access permissions in the form of mode bits: <emphasis role="bold">r</emphasis> (<emphasis | |
152 | role="bold">read</emphasis>), <emphasis role="bold">w</emphasis> (<emphasis role="bold">write</emphasis>), and <emphasis | |
153 | role="bold">x</emphasis> (<emphasis role="bold">execute</emphasis>). AFS defines seven permissions, which makes access | |
154 | control more precise. For detailed descriptions, see <link linkend="HDRWQ567">The AFS ACL Permissions</link>. | |
155 | <simplelist> | |
156 | <member><emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>)</member> | |
157 | ||
158 | <member><emphasis role="bold">d</emphasis> (<emphasis role="bold">delete</emphasis>)</member> | |
159 | ||
160 | <member><emphasis role="bold">i</emphasis> (<emphasis role="bold">insert</emphasis>)</member> | |
161 | ||
162 | <member><emphasis role="bold">k</emphasis> (<emphasis role="bold">lock</emphasis>)</member> | |
163 | ||
164 | <member><emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>)</member> | |
165 | ||
166 | <member><emphasis role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>)</member> | |
167 | ||
168 | <member><emphasis role="bold">w</emphasis> (<emphasis role="bold">write</emphasis>)</member> | |
169 | </simplelist></para> | |
170 | </listitem> | |
171 | ||
172 | <listitem> | |
173 | <para>Three defined users and groups (UFS) versus many (AFS)</para> | |
174 | ||
175 | <para>UFS controls access for one user and two groups by providing a set of mode bits for each: the user who owns the | |
176 | file or directory, a single defined group, and everyone who has an account on the system.</para> | |
177 | ||
178 | <para>AFS, in contrast, allows you to place many entries (individual users or groups) on an ACL, granting a different | |
179 | set of access permissions to each one. The number of possible entries is about 20, and depends on how much space each | |
180 | entry occupies in the memory allocated for the ACL itself.</para> | |
181 | ||
182 | <para>AFS defines two system groups, <emphasis role="bold">system:anyuser</emphasis> and <emphasis | |
183 | role="bold">system:authuser</emphasis>, which represent all users and all authenticated users, respectively; for further | |
184 | discussion, see <link linkend="HDRWQ571">Using Groups on ACLs</link>. In addition, users can define their own groups in | |
185 | the Protection Database, consisting of individual users or machine IP addresses. Users who have the <emphasis | |
186 | role="bold">a</emphasis> permission on an ACL can create entries for the system groups as well as groups defined by | |
187 | themselves or other users. For information on defining groups, see <link linkend="HDRWQ531">Administering the Protection | |
188 | Database</link>.</para> | |
189 | ||
190 | <para>When a user requests access to a file or directory, the File Server sums together all of the permissions that the | |
191 | relevant ACL extends to the user and to groups to which the user belongs. Placing group entries on ACLs therefore can | |
192 | control access for many more users than the ACL can accommodate as individual entries.</para> | |
193 | </listitem> | |
194 | </itemizedlist></para> | |
195 | </sect2> | |
196 | ||
197 | <sect2 id="HDRWQ567"> | |
198 | <title>The AFS ACL Permissions</title> | |
199 | ||
200 | <indexterm> | |
201 | <primary>access</primary> | |
202 | ||
203 | <secondary>permissions on ACL (see entries: <emphasis>permissions on ACL</emphasis>, <emphasis>ACL</emphasis>)</secondary> | |
204 | </indexterm> | |
205 | ||
206 | <indexterm> | |
207 | <primary>permissions on ACL</primary> | |
208 | ||
209 | <secondary>defined</secondary> | |
210 | </indexterm> | |
211 | ||
212 | <indexterm> | |
213 | <primary>ACL</primary> | |
214 | ||
215 | <secondary>permissions defined</secondary> | |
216 | </indexterm> | |
217 | ||
218 | <para>Functionally, the seven standard ACL permissions fall into two groups: one that applies to the directory itself and one | |
219 | that applies to the files it contains.</para> | |
220 | ||
221 | <sect3 id="HDRWQ568"> | |
222 | <title>The Four Directory Permissions</title> | |
223 | ||
224 | <para>The four permissions in this group are meaningful with respect to the directory itself. For example, the <emphasis | |
225 | role="bold">i</emphasis> (<emphasis role="bold">insert</emphasis>) permission does not control addition of data to a file, | |
226 | but rather creation of a new file or subdirectory. <variablelist> | |
227 | <varlistentry> | |
228 | <term><emphasis role="bold">The l (lookup) permission</emphasis></term> | |
229 | ||
230 | <listitem> | |
231 | <para>This permission functions as something of a gate keeper for access to the directory and its files, because a | |
232 | user must have it in order to exercise any other permissions. In particular, a user must have this permission to | |
233 | access anything in the directory's subdirectories, even if the ACL on a subdirectory grants extensive permissions. | |
234 | <indexterm> | |
235 | <primary>lookup ACL permission</primary> | |
236 | ||
237 | <secondary></secondary> | |
238 | ||
239 | <see>l ACL permission</see> | |
240 | </indexterm> <indexterm> | |
241 | <primary>l ACL permission</primary> | |
242 | </indexterm></para> | |
243 | ||
244 | <para>This permission enables a user to issue the following commands: <itemizedlist> | |
245 | <listitem> | |
246 | <para>The <emphasis role="bold">ls</emphasis> command to list the names of the files and subdirectories in the | |
247 | directory</para> | |
248 | </listitem> | |
249 | ||
250 | <listitem> | |
251 | <para>The <emphasis role="bold">ls -ld</emphasis> command to obtain complete status information for the | |
252 | directory element itself</para> | |
253 | </listitem> | |
254 | ||
255 | <listitem> | |
256 | <para>The <emphasis role="bold">fs listacl</emphasis> command to examine the directory's ACL</para> | |
257 | </listitem> | |
258 | </itemizedlist></para> | |
259 | ||
260 | <para>This permission does not enable a user to read the contents of a file in the directory, to issue the <emphasis | |
261 | role="bold">ls -l</emphasis> command on a file in the directory, or to issue the <emphasis role="bold">fs | |
262 | listacl</emphasis> command with the filename as the <emphasis role="bold">-path</emphasis> argument. Those | |
263 | operations require the <emphasis role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>) permission which | |
264 | is described in <link linkend="HDRWQ569">The Three File Permissions</link>.</para> | |
265 | ||
266 | <para>Similarly, this permission does not enable a user to issue the <emphasis role="bold">ls</emphasis>, <emphasis | |
267 | role="bold">ls -l</emphasis>, <emphasis role="bold">ls -ld</emphasis>, or <emphasis role="bold">fs | |
268 | listacl</emphasis> commands against a subdirectory of the directory. Those operations require the <emphasis | |
269 | role="bold">l</emphasis> permission on the ACL of the subdirectory itself.</para> | |
270 | </listitem> | |
271 | </varlistentry> | |
272 | ||
273 | <varlistentry> | |
274 | <term><emphasis role="bold">The i (insert) permission</emphasis></term> | |
275 | ||
276 | <listitem> | |
277 | <para>This permission enables a user to add new files to the directory, either by creating or copying, and to create | |
278 | new subdirectories. It does not extend into any subdirectories, which are protected by their own ACLs. <indexterm> | |
279 | <primary>insert ACL permission</primary> | |
280 | ||
281 | <secondary></secondary> | |
282 | ||
283 | <see>i ACL permission</see> | |
284 | </indexterm> <indexterm> | |
285 | <primary>i ACL permission</primary> | |
286 | </indexterm></para> | |
287 | </listitem> | |
288 | </varlistentry> | |
289 | ||
290 | <varlistentry> | |
291 | <term><emphasis role="bold">The d (delete) permission</emphasis></term> | |
292 | ||
293 | <listitem> | |
294 | <para>This permission enables a user to remove files and subdirectories from the directory or move them into other | |
295 | directories (assuming that the user has the <emphasis role="bold">i</emphasis> permission on the ACL of the other | |
296 | directories). <indexterm> | |
297 | <primary>delete ACL permission</primary> | |
298 | ||
299 | <secondary></secondary> | |
300 | ||
301 | <see>d ACL permission</see> | |
302 | </indexterm> <indexterm> | |
303 | <primary>d ACL permission</primary> | |
304 | </indexterm></para> | |
305 | </listitem> | |
306 | </varlistentry> | |
307 | ||
308 | <varlistentry> | |
309 | <term><emphasis role="bold">The a (administer) permission</emphasis></term> | |
310 | ||
311 | <listitem> | |
312 | <para>This permission enables a user to change the directory's ACL. Members of the | |
313 | <emphasis role="bold">system:administrators</emphasis> group implicitly have | |
314 | this permission on every directory (that is, even if that group does not appear on | |
315 | the ACL). Similarly, the owner of a volume root directory implicitly has this | |
316 | permission on its ACL and those of all directories within the volume. <indexterm> | |
317 | <primary>administer ACL permission</primary> | |
318 | <secondary/> | |
319 | <see>a ACL permission</see> | |
320 | </indexterm> | |
321 | <indexterm> | |
322 | <primary>a ACL permission</primary> | |
323 | </indexterm><indexterm> | |
324 | <primary>implicit ACL permissions</primary> | |
325 | </indexterm></para> | |
326 | </listitem> | |
327 | </varlistentry> | |
328 | </variablelist></para> | |
329 | </sect3> | |
330 | ||
331 | <sect3 id="HDRWQ569"> | |
332 | <title>The Three File Permissions</title> | |
333 | ||
334 | <para>The three permissions in this group are meaningful with respect to files in a directory, rather than the directory | |
335 | itself or its subdirectories. <variablelist> | |
336 | <varlistentry> | |
337 | <term><emphasis role="bold">The r (read) permission</emphasis></term> | |
338 | ||
339 | <listitem> | |
340 | <para>This permission enables a user to read the contents of files in the directory and to issue the <emphasis | |
341 | role="bold">ls -l</emphasis> command to stat the file elements. <indexterm> | |
342 | <primary>read</primary> | |
343 | ||
344 | <secondary>ACL permission</secondary> | |
345 | ||
346 | <see>r ACL permission)</see> | |
347 | </indexterm> <indexterm> | |
348 | <primary>r ACL permission</primary> | |
349 | </indexterm></para> | |
350 | </listitem> | |
351 | </varlistentry> | |
352 | ||
353 | <varlistentry> | |
354 | <term><emphasis role="bold">The w (write) permission</emphasis></term> | |
355 | ||
356 | <listitem> | |
357 | <para>This permission enables a user to modify the contents of files in the directory and to issue the <emphasis | |
358 | role="bold">chmod</emphasis> command to change their UNIX mode bits. <indexterm> | |
359 | <primary>write</primary> | |
360 | ||
361 | <secondary>ACL permission</secondary> | |
362 | ||
363 | <see>write ACL permission</see> | |
364 | </indexterm> <indexterm> | |
365 | <primary>w ACL permission</primary> | |
366 | </indexterm></para> | |
367 | </listitem> | |
368 | </varlistentry> | |
369 | ||
370 | <varlistentry> | |
371 | <term><emphasis role="bold">The k (lock) permission</emphasis></term> | |
372 | ||
373 | <listitem> | |
374 | <para>This permission enables the user to run programs that issue system calls to lock files in the directory. | |
375 | <indexterm> | |
376 | <primary>lock ACL permission</primary> | |
377 | ||
378 | <secondary></secondary> | |
379 | ||
380 | <see>k ACL permission</see> | |
381 | </indexterm> <indexterm> | |
382 | <primary>k ACL permission</primary> | |
383 | </indexterm></para> | |
384 | </listitem> | |
385 | </varlistentry> | |
386 | </variablelist></para> | |
387 | </sect3> | |
388 | ||
389 | <sect3 id="Header_635"> | |
390 | <title>The Eight Auxiliary Permissions</title> | |
391 | ||
392 | <indexterm> | |
393 | <primary>undefined ACL permissions</primary> | |
394 | </indexterm> | |
395 | ||
396 | <indexterm> | |
397 | <primary>auxiliary ACL permissions</primary> | |
398 | </indexterm> | |
399 | ||
400 | <indexterm> | |
401 | <primary>ACL</primary> | |
402 | ||
403 | <secondary>auxiliary permissions</secondary> | |
404 | </indexterm> | |
405 | ||
406 | <para>AFS provides eight additional permissions that do not have a defined meaning, denoted by the uppercase letters | |
407 | <emphasis role="bold">A</emphasis>, <emphasis role="bold">B</emphasis>, <emphasis role="bold">C</emphasis>, <emphasis | |
408 | role="bold">D</emphasis>, <emphasis role="bold">E</emphasis>, <emphasis role="bold">F</emphasis>, <emphasis | |
409 | role="bold">G</emphasis>, and <emphasis role="bold">H</emphasis>.</para> | |
410 | ||
411 | <para>You can write application programs that assign a meaning to one or more of the permissions, and then place them on | |
412 | ACLs to control file access by those programs. For example, you can modify a print program to recognize and interpret the | |
413 | permissions, and then place them on directories that house files that the program accesses. Use the <emphasis role="bold">fs | |
414 | listacl</emphasis> and <emphasis role="bold">fs setacl</emphasis> commands to display and set the auxiliary permissions on | |
415 | ACLs just like the standard seven.</para> | |
416 | </sect3> | |
417 | ||
418 | <sect3 id="Header_636"> | |
419 | <title>Shorthand Notation for Sets of Permissions</title> | |
420 | ||
421 | <indexterm> | |
422 | <primary>ACL</primary> | |
423 | ||
424 | <secondary>shorthand notation for grouping permissions</secondary> | |
425 | </indexterm> | |
426 | ||
427 | <indexterm> | |
428 | <primary>shorthand notation</primary> | |
429 | ||
430 | <secondary>ACL permissions</secondary> | |
431 | </indexterm> | |
432 | ||
433 | <para>You can combine the seven permissions in any way in an ACL entry, but certain combinations are more useful than | |
434 | others. Four of the more common combinations have corresponding shorthand forms. When using the <emphasis role="bold">fs | |
435 | setacl</emphasis> command to define ACL entries, you can provide either one or more of the individual letters that represent | |
436 | the permissions, or one of the following shorthand forms: <variablelist> | |
437 | <indexterm> | |
438 | <primary>all shorthand for ACL permissions</primary> | |
439 | </indexterm> | |
440 | ||
441 | <varlistentry> | |
442 | <term><emphasis role="bold">all</emphasis></term> | |
443 | ||
444 | <listitem> | |
445 | <para>Represents all seven standard permissions (<emphasis role="bold">rlidwka</emphasis>). <indexterm> | |
446 | <primary>none shorthand for ACL permissions</primary> | |
447 | </indexterm></para> | |
448 | </listitem> | |
449 | </varlistentry> | |
450 | ||
451 | <varlistentry> | |
452 | <term><emphasis role="bold">none</emphasis></term> | |
453 | ||
454 | <listitem> | |
455 | <para>Removes the entry from the ACL, leaving the user or group with no permissions. <indexterm> | |
456 | <primary>read</primary> | |
457 | ||
458 | <secondary>shorthand for ACL permissions</secondary> | |
459 | </indexterm></para> | |
460 | </listitem> | |
461 | </varlistentry> | |
462 | ||
463 | <varlistentry> | |
464 | <term><emphasis role="bold">read</emphasis></term> | |
465 | ||
466 | <listitem> | |
467 | <para>Represents the <emphasis role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>) and <emphasis | |
468 | role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) permissions. <indexterm> | |
469 | <primary>write</primary> | |
470 | ||
471 | <secondary>shorthand for ACL permissions</secondary> | |
472 | </indexterm></para> | |
473 | </listitem> | |
474 | </varlistentry> | |
475 | ||
476 | <varlistentry> | |
477 | <term><emphasis role="bold">write</emphasis></term> | |
478 | ||
479 | <listitem> | |
480 | <para>Represents all permissions except <emphasis role="bold">a</emphasis> (<emphasis | |
481 | role="bold">administer</emphasis>): <emphasis role="bold">rlidwk</emphasis>.</para> | |
482 | </listitem> | |
483 | </varlistentry> | |
484 | </variablelist></para> | |
485 | </sect3> | |
486 | </sect2> | |
487 | ||
488 | <sect2 id="HDRWQ570"> | |
489 | <title>Using Normal and Negative Permissions</title> | |
490 | ||
491 | <indexterm> | |
492 | <primary>ACL</primary> | |
493 | ||
494 | <secondary>normal vs. negative permissions</secondary> | |
495 | </indexterm> | |
496 | ||
497 | <indexterm> | |
498 | <primary>normal ACL permissions</primary> | |
499 | ||
500 | <secondary>defined</secondary> | |
501 | </indexterm> | |
502 | ||
503 | <indexterm> | |
504 | <primary>negative ACL permissions</primary> | |
505 | ||
506 | <secondary>defined</secondary> | |
507 | </indexterm> | |
508 | ||
509 | <para>ACLs enable you both to grant and to deny access to a directory and the files in it. To grant access, use the <emphasis | |
510 | role="bold">fs setacl</emphasis> command to create an ACL entry that associates a set of permissions with a user or group, as | |
511 | described in <link linkend="HDRWQ573">Setting ACL Entries</link>. When you use the <emphasis role="bold">fs listacl</emphasis> | |
512 | command to display an ACL (as described in <link linkend="HDRWQ572">Displaying ACLs</link>), such entries appear underneath | |
513 | the following header, which uses the term <emphasis>rights</emphasis> to refer to permissions:</para> | |
514 | ||
515 | <programlisting> | |
516 | Normal rights | |
517 | </programlisting> | |
518 | ||
519 | <para>There are two ways to deny access: <orderedlist> | |
520 | <listitem> | |
521 | <para>The recommended method is simply to omit an entry for the user or group from the ACL, or to omit the appropriate | |
522 | permissions from the entry. Use the <emphasis role="bold">fs setacl</emphasis> command to remove or edit an existing | |
523 | entry, using the instructions in <link linkend="HDRWQ574">To add, remove, or edit normal ACL permissions</link>. In most | |
524 | circumstances, this method is enough to prevent access of certain kinds or by certain users. You must take care, | |
525 | however, not to grant the undesired permissions to any groups to which such users belong.</para> | |
526 | </listitem> | |
527 | ||
528 | <listitem> | |
529 | <para>The more explicit method for denying access is to use the <emphasis role="bold">-negative</emphasis> flag to the | |
530 | <emphasis role="bold">fs setacl</emphasis> command to create an entry that associates <emphasis>negative | |
531 | permissions</emphasis> with the user or group; for instructions, see <link linkend="HDRWQ575">To add, remove, or edit | |
532 | negative ACL permissions</link>. The output from the <emphasis role="bold">fs listacl</emphasis> command lists negative | |
533 | entries underneath the following header: <programlisting> | |
534 | Negative rights | |
535 | </programlisting></para> | |
536 | ||
537 | <para>When determining what type of access to grant to a user, the File Server first compiles a set of permissions by | |
538 | examining all of the entries in the <computeroutput>Normal rights</computeroutput> section of the ACL. It then subtracts | |
539 | any permissions associated with the user (or with groups to which the user belongs) on the <computeroutput>Negative | |
540 | rights</computeroutput> section of the ACL. Therefore, negative permissions always cancel out normal permissions.</para> | |
541 | ||
542 | <para>Using negative permissions reverses the usual semantics of the <emphasis role="bold">fs setacl</emphasis> command, | |
543 | introducing the potential for confusion. In particular, combining the <emphasis role="bold">none</emphasis> shorthand | |
544 | and the <emphasis role="bold">-negative</emphasis> flag constitutes a double negative: by removing an entry from the | |
545 | <computeroutput>Negative rights</computeroutput> section of the ACL, you enable a user once again to obtain permissions | |
546 | via entries in the <computeroutput>Normal rights</computeroutput> section. Combining the <emphasis | |
547 | role="bold">all</emphasis> shorthand with the <emphasis role="bold">-negative</emphasis> flag explicitly denies all | |
548 | permissions.</para> | |
549 | ||
550 | <para>Note also that it is pointless to create an entry in the <computeroutput>Negative rights</computeroutput> section | |
551 | if an entry in the <computeroutput>Normal rights</computeroutput> section grants the denied permissions to the <emphasis | |
552 | role="bold">system:anyuser</emphasis> group. In this case, users can obtain the permissions simply by using the | |
553 | <emphasis role="bold">unlog</emphasis> command to discard their tokens. When they do so, the File Server recognizes them | |
554 | as the <emphasis role="bold">anonymous</emphasis> user, who belongs to the <emphasis | |
555 | role="bold">system:anyuser</emphasis> group but does not match the entries on the <computeroutput>Negative | |
556 | rights</computeroutput> section of the ACL.</para> | |
557 | </listitem> | |
558 | </orderedlist></para> | |
559 | </sect2> | |
560 | ||
561 | <sect2 id="HDRWQ571"> | |
562 | <title>Using Groups on ACLs</title> | |
563 | ||
564 | <indexterm> | |
565 | <primary>group</primary> | |
566 | ||
567 | <secondary>ACL entry, usefulness of</secondary> | |
568 | </indexterm> | |
569 | ||
570 | <indexterm> | |
571 | <primary>ACL</primary> | |
572 | ||
573 | <secondary>group entries, usefulness</secondary> | |
574 | </indexterm> | |
575 | ||
576 | <para>As previously mentioned, placing a group entry on an ACL enables you to control access for many users at once. You can | |
577 | grant a new user access to many files and directories simply by adding the user to a group that appears on the relevant ACLs. | |
578 | You can also create groups of machines, in which case any user logged on to the machine obtains the access that is granted to | |
579 | the group. On directories where they have the <emphasis role="bold">a</emphasis> permission on the ACL, users can define their | |
580 | own groups and can create ACL entries for any groups, not just groups that they create or own themselves. For instructions on | |
581 | creating groups of users or machines, and a discussion of the most effective ways to use different types of groups, see <link | |
582 | linkend="HDRWQ531">Administering the Protection Database</link>. <indexterm> | |
583 | <primary>system groups</primary> | |
584 | ||
585 | <secondary>using on ACLs</secondary> | |
586 | </indexterm> <indexterm> | |
587 | <primary>group</primary> | |
588 | ||
589 | <secondary>system-defined on ACLs</secondary> | |
590 | </indexterm> <indexterm> | |
591 | <primary>ACL</primary> | |
592 | ||
593 | <secondary>system groups on</secondary> | |
594 | </indexterm> <indexterm> | |
595 | <primary>system:anyuser group</primary> | |
596 | ||
597 | <secondary>using on ACLs</secondary> | |
598 | </indexterm> <indexterm> | |
599 | <primary>system:authuser group</primary> | |
600 | ||
601 | <secondary>using on ACLs</secondary> | |
602 | </indexterm></para> | |
603 | ||
604 | <para>AFS also defines the following two system groups, which can be very useful on ACLs because they potentially represent a | |
605 | large group of people. For more information about these groups, see <link linkend="HDRWQ535">The System Groups</link>. | |
606 | <variablelist> | |
607 | <varlistentry> | |
608 | <term><emphasis role="bold">system:anyuser</emphasis></term> | |
609 | ||
610 | <listitem> | |
611 | <para>Includes anyone who can access the cell's file tree, including users who have logged in as the local superuser | |
612 | <emphasis role="bold">root</emphasis>, have connected to a local machine from somewhere outside the cell, and AFS | |
613 | users who belong to a foreign cell. This group includes users who do not have tokens that are valid for the local AFS | |
614 | servers; the servers recognize them as the user <emphasis role="bold">anonymous</emphasis>.</para> | |
615 | ||
616 | <para>Note that creating an ACL entry for this group is the only way to extend access to AFS users from foreign cells, | |
617 | unless you create local authentication accounts for them. <indexterm> | |
618 | <primary>ACL</primary> | |
619 | ||
620 | <secondary>foreign users on</secondary> | |
621 | </indexterm></para> | |
622 | </listitem> | |
623 | </varlistentry> | |
624 | ||
625 | <varlistentry> | |
626 | <term><emphasis role="bold">system:authuser</emphasis></term> | |
627 | ||
628 | <listitem> | |
629 | <para>Includes all users who have a valid AFS token obtained from the local cell's authentication service.</para> | |
630 | </listitem> | |
631 | </varlistentry> | |
632 | </variablelist></para> | |
633 | ||
634 | <para>It is particularly useful to grant the <emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) | |
635 | permission to the <emphasis role="bold">system:anyuser</emphasis> group on the ACL of most directories in the file system, | |
636 | especially at the upper levels. This permission enables users only to learn the names of files and subdirectories in a | |
637 | directory, but without it they cannot traverse their way through the directories in the path to a target file.</para> | |
638 | ||
639 | <para>A slightly more restrictive alternative is to grant the <emphasis role="bold">l</emphasis> permission to the <emphasis | |
640 | role="bold">system:authuser</emphasis> group. If that is still not restrictive enough, you can grant the <emphasis | |
641 | role="bold">l</emphasis> to specific users or groups, which cannot exceed about 20 in number on a given ACL.</para> | |
642 | ||
643 | <para>Another reason to grant certain permissions to the <emphasis role="bold">system:anyuser</emphasis> group is to enable | |
644 | the correct operation of processes that provide services such as printing and mail delivery. For example, in addition to the | |
645 | <emphasis role="bold">l</emphasis> permission, a print process possibly needs the <emphasis role="bold">r</emphasis> | |
646 | (<emphasis role="bold">read</emphasis>) permission in order to access the contents of files, and a mail delivery process | |
647 | possibly requires the <emphasis role="bold">i</emphasis> (<emphasis role="bold">insert</emphasis>) permission to deliver new | |
648 | pieces of mail.</para> | |
649 | ||
650 | <para>The ACL on the root directory of every newly created volume grants all permissions to the <emphasis | |
651 | role="bold">system:administrators</emphasis> group. You can remove this entry if you wish, but members of the <emphasis | |
652 | role="bold">system:administrators</emphasis> group always implicitly have the <emphasis role="bold">a</emphasis> (<emphasis | |
653 | role="bold">administer</emphasis>), and by default also the <emphasis role="bold">l</emphasis>, permission on every | |
654 | directory's ACL. The <emphasis role="bold">a</emphasis> permission enables them to grant themselves other permissions | |
655 | explicitly when necessary. To learn about changing this default set of permissions, see <link linkend="HDRWQ586">Administering | |
656 | the system:administrators Group</link>.</para> | |
657 | </sect2> | |
658 | </sect1> | |
659 | ||
660 | <sect1 id="HDRWQ572"> | |
661 | <title>Displaying ACLs</title> | |
662 | ||
663 | <indexterm> | |
664 | <primary>ACL</primary> | |
665 | ||
666 | <secondary>displaying</secondary> | |
667 | </indexterm> | |
668 | ||
669 | <indexterm> | |
670 | <primary>displaying</primary> | |
671 | ||
672 | <secondary>ACL entries</secondary> | |
673 | </indexterm> | |
674 | ||
675 | <para>To display the ACL associated with a file, directory or symbolic link, issue the <emphasis role="bold">fs | |
676 | listacl</emphasis> command. The output for a symbolic link displays the ACL that applies to its target file or directory, rather | |
677 | than the ACL on the directory that houses the symbolic link.</para> | |
678 | ||
679 | <para><emphasis role="bold">Note for AFS/DFS Migration Toolkit users:</emphasis> If the machine on which you issue the <emphasis | |
680 | role="bold">fs listacl</emphasis> command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, | |
681 | you can use the command to display the ACL on DFS files and directories. To display a DFS directory's Initial Container and | |
682 | Initial Object ACL instead of the regular one, include the <emphasis role="bold">fs listacl</emphasis> command's <emphasis | |
683 | role="bold">-id</emphasis> or <emphasis role="bold">-if</emphasis> flag. For instructions, see the <emphasis>OpenAFS/DFS | |
684 | Migration Toolkit Administration Guide and Reference</emphasis>. The <emphasis role="bold">fs</emphasis> command interpreter | |
685 | ignores the <emphasis role="bold">-id</emphasis> and <emphasis role="bold">-if</emphasis> flags if you include them when | |
686 | displaying an AFS ACL. <indexterm> | |
687 | <primary>fs commands</primary> | |
688 | ||
689 | <secondary>listacl</secondary> | |
690 | </indexterm><indexterm> | |
691 | <primary>commands</primary> | |
692 | ||
693 | <secondary>fs listacl</secondary> | |
694 | </indexterm></para> | |
695 | ||
696 | <sect2 id="Header_640"> | |
697 | <title>To display an ACL</title> | |
698 | ||
699 | <orderedlist> | |
700 | <listitem> | |
701 | <para>Issue the <emphasis role="bold">fs listacl</emphasis> command. <programlisting> | |
702 | % <emphasis role="bold">fs listacl</emphasis> [<<replaceable>dir/file path</replaceable>>+] | |
703 | </programlisting></para> | |
704 | ||
705 | <para>where</para> | |
706 | ||
707 | <variablelist> | |
708 | <varlistentry> | |
709 | <term><emphasis role="bold">la</emphasis></term> | |
710 | ||
711 | <listitem> | |
712 | <para>Is an acceptable alias for <emphasis role="bold">listacl</emphasis> (and <emphasis | |
713 | role="bold">lista</emphasis> is the shortest acceptable abbreviation).</para> | |
714 | </listitem> | |
715 | </varlistentry> | |
716 | ||
717 | <varlistentry> | |
718 | <term><emphasis role="bold">dir/file path</emphasis></term> | |
719 | ||
720 | <listitem> | |
721 | <para>Names one or more files or directories for which to display the ACL. For files, the output displays the ACL | |
722 | for its directory. If you omit this argument, the output is for the current working directory. Partial pathnames are | |
723 | interpreted relative to the current working directory. You can also use the following notation on its own or as part | |
724 | of a pathname: <variablelist> | |
725 | <varlistentry> | |
726 | <term><emphasis role="bold">.</emphasis></term> | |
727 | ||
728 | <listitem> | |
729 | <para>(A single period). Specifies the current working directory.</para> | |
730 | </listitem> | |
731 | </varlistentry> | |
732 | ||
733 | <varlistentry> | |
734 | <term><emphasis role="bold">..</emphasis></term> | |
735 | ||
736 | <listitem> | |
737 | <para>(Two periods). Specifies the current working directory's parent directory.</para> | |
738 | </listitem> | |
739 | </varlistentry> | |
740 | ||
741 | <varlistentry> | |
742 | <term><emphasis role="bold">*</emphasis></term> | |
743 | ||
744 | <listitem> | |
745 | <para>(The asterisk). Specifies each file and subdirectory in the current working directory. The ACL | |
746 | displayed for a file is always the same as for its directory, but the ACL for each subdirectory can | |
747 | differ.</para> | |
748 | </listitem> | |
749 | </varlistentry> | |
750 | </variablelist></para> | |
751 | </listitem> | |
752 | </varlistentry> | |
753 | </variablelist> | |
754 | </listitem> | |
755 | </orderedlist> | |
756 | ||
757 | <para>The following error message indicates that you do not have the permissions needed to display an ACL. To specify a | |
758 | directory name as the dir/file path argument, you must have the <emphasis role="bold">l</emphasis> (<emphasis | |
759 | role="bold">lookup</emphasis>) permission on the ACL. To specify a filename, you must also have the <emphasis | |
760 | role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>) permission on its directory's ACL.</para> | |
761 | ||
762 | <programlisting> | |
763 | fs: You don't have the required access permissions on 'dir/file path' | |
764 | </programlisting> | |
765 | ||
766 | <para>Members of the <emphasis role="bold">system:administrators</emphasis> group and the directory's owner (as reported by | |
767 | the <emphasis role="bold">ls -ld</emphasis> command) implicitly have the <emphasis role="bold">a</emphasis> (<emphasis | |
768 | role="bold">administer</emphasis>) permission on every directory's ACL, and can use the <emphasis role="bold">fs | |
769 | setacl</emphasis> command to grant themselves the required permissions; for instructions, see <link linkend="HDRWQ573">Setting | |
770 | ACL Entries</link>.</para> | |
771 | ||
772 | <para>The output for each file or directory specified as dir/file path begins with the following header to identify it:</para> | |
773 | ||
774 | <programlisting> | |
775 | Access list for dir/file path is | |
776 | </programlisting> | |
777 | ||
778 | <para>The <computeroutput>Normal rights</computeroutput> header appears on the next line, followed by lines that each pair a | |
779 | user or group name and a set of permissions. The permissions appear as the single letters defined in <link | |
780 | linkend="HDRWQ567">The AFS ACL Permissions</link>, and always in the order <emphasis role="bold">rlidwka</emphasis>. If there | |
781 | are any negative permissions, the <computeroutput>Negative rights</computeroutput> header appears next, followed by pairs of | |
782 | negative permissions.</para> | |
783 | ||
784 | <para>The following example displays the ACL on user <emphasis role="bold">terry</emphasis>'s home directory in the Example | |
785 | Corporation cell:</para> | |
786 | ||
787 | <programlisting> | |
788 | % <emphasis role="bold">fs la /afs/example.com/usr/terry</emphasis> | |
789 | Access list for /afs/example.com/usr/terry is | |
790 | Normal permissions: | |
791 | system:authuser rl | |
792 | pat rlw | |
793 | terry rlidwka | |
794 | Negative permissions: | |
795 | terry:other-dept rl | |
796 | jones rl | |
797 | </programlisting> | |
798 | ||
799 | <para>where <emphasis role="bold">pat</emphasis>, <emphasis role="bold">terry</emphasis>, and <emphasis | |
800 | role="bold">jones</emphasis> are individual users, <emphasis role="bold">system:authuser</emphasis> is a system group, and | |
801 | <emphasis role="bold">terry:other-dept</emphasis> is a group that <emphasis role="bold">terry</emphasis> owns. The list of | |
802 | normal permissions grants all permissions to <emphasis role="bold">terry</emphasis>, the <emphasis role="bold">r</emphasis> | |
803 | (<emphasis role="bold">read</emphasis>), <emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>), and | |
804 | <emphasis role="bold">w</emphasis> (<emphasis role="bold">write</emphasis>) permissions to <emphasis | |
805 | role="bold">pat</emphasis>, and the <emphasis role="bold">r</emphasis> and <emphasis role="bold">l</emphasis> permissions to | |
806 | the members of the <emphasis role="bold">system:authuser</emphasis> group.</para> | |
807 | ||
808 | <para>The list of negative permissions denies the <emphasis role="bold">r</emphasis> and <emphasis role="bold">l</emphasis> | |
809 | permissions to <emphasis role="bold">jones</emphasis> and the members of the <emphasis role="bold">terry:other-dept</emphasis> | |
810 | group. These entries effectively prevent them from accessing <emphasis role="bold">terry</emphasis>'s home directory in any | |
811 | way, because they cancel out the <emphasis role="bold">r</emphasis> and <emphasis role="bold">l</emphasis> permissions | |
812 | extended to the <emphasis role="bold">system:authuser</emphasis> group, which is the only entry on the <computeroutput>Normal | |
813 | rights</computeroutput> section of the ACL that possibly applies to them.</para> | |
814 | </sect2> | |
815 | </sect1> | |
816 | ||
817 | <sect1 id="HDRWQ573"> | |
818 | <title>Setting ACL Entries</title> | |
819 | ||
820 | <indexterm> | |
821 | <primary>ACL</primary> | |
822 | ||
823 | <secondary>setting entries</secondary> | |
824 | </indexterm> | |
825 | ||
826 | <indexterm> | |
827 | <primary>ACL</primary> | |
828 | ||
829 | <secondary>editing entries</secondary> | |
830 | </indexterm> | |
831 | ||
832 | <indexterm> | |
833 | <primary>ACL</primary> | |
834 | ||
835 | <secondary>adding entries</secondary> | |
836 | </indexterm> | |
837 | ||
838 | <indexterm> | |
839 | <primary>ACL</primary> | |
840 | ||
841 | <secondary>removing entries</secondary> | |
842 | </indexterm> | |
843 | ||
844 | <indexterm> | |
845 | <primary>changing</primary> | |
846 | ||
847 | <secondary>ACL entries</secondary> | |
848 | </indexterm> | |
849 | ||
850 | <indexterm> | |
851 | <primary>setting</primary> | |
852 | ||
853 | <secondary>ACL entries</secondary> | |
854 | </indexterm> | |
855 | ||
856 | <indexterm> | |
857 | <primary>granting</primary> | |
858 | ||
859 | <secondary>file access by setting ACL</secondary> | |
860 | </indexterm> | |
861 | ||
862 | <indexterm> | |
863 | <primary>creating</primary> | |
864 | ||
865 | <secondary>ACL entry</secondary> | |
866 | </indexterm> | |
867 | ||
868 | <indexterm> | |
869 | <primary>adding</primary> | |
870 | ||
871 | <secondary>ACL entry</secondary> | |
872 | ||
873 | <tertiary>normal permissions</tertiary> | |
874 | </indexterm> | |
875 | ||
876 | <indexterm> | |
877 | <primary>removing</primary> | |
878 | ||
879 | <secondary>ACL entry</secondary> | |
880 | </indexterm> | |
881 | ||
882 | <para>To add, remove, or edit ACL entries, use the <emphasis role="bold">fs setacl</emphasis> command. By default, the command | |
883 | manipulates entries on the normal permissions section of the ACL. To manipulate entries on the negative permissions section, | |
884 | include the <emphasis role="bold">-negative</emphasis> flag.</para> | |
885 | ||
886 | <para>You must have the <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission on an ACL to | |
887 | edit it. The owner of a directory (as reported by the <emphasis role="bold">ls -ld</emphasis>) command and members of the | |
888 | <emphasis role="bold">system:administrators</emphasis> group always implicitly have it on every ACL. By default, members of the | |
889 | <emphasis role="bold">system:administrators</emphasis> group also implicitly have the <emphasis role="bold">l</emphasis> | |
890 | (<emphasis role="bold">lookup</emphasis>) permission.</para> | |
891 | ||
892 | <para><emphasis role="bold">Note for AFS/DFS Migration Toolkit users:</emphasis> If the machine on which you issue the <emphasis | |
893 | role="bold">fs setacl</emphasis> command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, | |
894 | you can use the command to set the ACL on DFS files and directories. To set a DFS directory's Initial Container and Initial | |
895 | Object ACL instead of the regular one, include the <emphasis role="bold">fs setacl</emphasis> command's <emphasis | |
896 | role="bold">-id</emphasis> or <emphasis role="bold">-if</emphasis> flag. For instructions, see the <emphasis>OpenAFS/DFS | |
897 | Migration Toolkit Administration Guide and Reference</emphasis>. The <emphasis role="bold">fs</emphasis> command interpreter | |
898 | ignores the <emphasis role="bold">-id</emphasis> and <emphasis role="bold">-if</emphasis> flags if you include them when setting | |
899 | an AFS ACL. <indexterm> | |
900 | <primary>fs commands</primary> | |
901 | ||
902 | <secondary>setacl</secondary> | |
903 | </indexterm><indexterm> | |
904 | <primary>commands</primary> | |
905 | ||
906 | <secondary>fs setacl</secondary> | |
907 | </indexterm></para> | |
908 | ||
909 | <sect2 id="HDRWQ574"> | |
910 | <title>To add, remove, or edit normal ACL permissions</title> | |
911 | ||
912 | <orderedlist> | |
913 | <listitem> | |
914 | <para>Verify that you have the <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission | |
915 | on each directory for which you are editing the ACL. If necessary, issue the <emphasis role="bold">fs listacl</emphasis> | |
916 | command, which is fully described in <link linkend="HDRWQ572">Displaying ACLs</link>. <programlisting> | |
917 | % <emphasis role="bold">fs listacl</emphasis> [<<replaceable>dir/file path</replaceable>>] | |
918 | </programlisting></para> | |
919 | </listitem> | |
920 | ||
921 | <listitem> | |
922 | <para>Issue the <emphasis role="bold">fs setacl</emphasis> command to edit entries in the normal permissions section of | |
923 | the ACL. To remove an entry, specify the <emphasis role="bold">none</emphasis> shorthand as the permissions. If an ACL | |
924 | entry already exists, the permissions you specify completely replace those in the existing entry. <programlisting> | |
925 | % <emphasis role="bold">fs setacl -dir</emphasis> <<replaceable>directory</replaceable>>+ <emphasis role="bold">-acl</emphasis> <<replaceable>access list entries</replaceable>>+ | |
926 | </programlisting></para> | |
927 | ||
928 | <para>where</para> | |
929 | ||
930 | <variablelist> | |
931 | <varlistentry> | |
932 | <term><emphasis role="bold">sa</emphasis></term> | |
933 | ||
934 | <listitem> | |
935 | <para>Is an acceptable alias for <emphasis role="bold">setacl</emphasis> (and <emphasis role="bold">seta</emphasis> | |
936 | is the shortest acceptable abbreviation).</para> | |
937 | </listitem> | |
938 | </varlistentry> | |
939 | ||
940 | <varlistentry> | |
941 | <term><emphasis role="bold">-dir</emphasis></term> | |
942 | ||
943 | <listitem> | |
944 | <para>Names one or more directories to which to apply the ACL entries defined by the <emphasis | |
945 | role="bold">-acl</emphasis> argument. Partial pathnames are interpreted relative to the current working | |
946 | directory.</para> | |
947 | ||
948 | <para>Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a | |
949 | read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the | |
950 | pathname's second level (for example, <emphasis role="bold">/afs/.example.com</emphasis>). For further discussion of the | |
951 | concept of read/write and read-only paths through the filespace, see <link linkend="HDRWQ209">The Rules of Mount | |
952 | Point Traversal</link>.</para> | |
953 | ||
954 | <para>You can also use the following notation on its own or as part of a pathname:</para> | |
955 | ||
956 | <variablelist> | |
957 | <varlistentry> | |
958 | <term><emphasis role="bold">.</emphasis></term> | |
959 | ||
960 | <listitem> | |
961 | <para>(A single period). If used by itself, sets the ACL on the current working directory.</para> | |
962 | </listitem> | |
963 | </varlistentry> | |
964 | ||
965 | <varlistentry> | |
966 | <term><emphasis role="bold">..</emphasis></term> | |
967 | ||
968 | <listitem> | |
969 | <para>(Two periods). If used by itself, sets the ACL on the current working directory's parent | |
970 | directory.</para> | |
971 | </listitem> | |
972 | </varlistentry> | |
973 | ||
974 | <varlistentry> | |
975 | <term><emphasis role="bold">*</emphasis></term> | |
976 | ||
977 | <listitem> | |
978 | <para>(The asterisk). Sets the ACL on each of the subdirectories in the current working directory. You must | |
979 | precede it with the <emphasis role="bold">-dir</emphasis> switch, since it potentially designates multiple | |
980 | directories. The <emphasis role="bold">fs</emphasis> command interpreter generates the following error message | |
981 | for each file in the directory: <programlisting> | |
982 | fs: 'filename': Not a directory | |
983 | </programlisting></para> | |
984 | </listitem> | |
985 | </varlistentry> | |
986 | </variablelist> | |
987 | ||
988 | <para>If you specify only one directory or file name, you can omit the <emphasis role="bold">-dir</emphasis> and | |
989 | <emphasis role="bold">-acl</emphasis> switches.</para> | |
990 | </listitem> | |
991 | </varlistentry> | |
992 | ||
993 | <varlistentry> | |
994 | <term><emphasis role="bold">-acl</emphasis></term> | |
995 | ||
996 | <listitem> | |
997 | <para>Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate | |
998 | the pairs, and the two parts of each pair, with one or more spaces.</para> | |
999 | ||
1000 | <para>To define the permissions, provide either:</para> | |
1001 | ||
1002 | <itemizedlist> | |
1003 | <listitem> | |
1004 | <para>One or more of the letters that represent the standard or auxiliary permissions (<emphasis | |
1005 | role="bold">rlidwka</emphasis> and <emphasis role="bold">ABCDEFGH</emphasis>), in any order</para> | |
1006 | </listitem> | |
1007 | ||
1008 | <listitem> | |
1009 | <para>One of the four shorthand notations: <itemizedlist> | |
1010 | <listitem> | |
1011 | <para><emphasis role="bold">all</emphasis> (equals <emphasis role="bold">rlidwka</emphasis>)</para> | |
1012 | </listitem> | |
1013 | ||
1014 | <listitem> | |
1015 | <para><emphasis role="bold">none</emphasis> (removes the entry)</para> | |
1016 | </listitem> | |
1017 | ||
1018 | <listitem> | |
1019 | <para><emphasis role="bold">read</emphasis> (equals <emphasis role="bold">rl</emphasis>)</para> | |
1020 | </listitem> | |
1021 | ||
1022 | <listitem> | |
1023 | <para><emphasis role="bold">write</emphasis> (equals <emphasis role="bold">rlidwk</emphasis>)</para> | |
1024 | </listitem> | |
1025 | </itemizedlist></para> | |
1026 | </listitem> | |
1027 | </itemizedlist> | |
1028 | ||
1029 | <para>For a more detailed description of the permissions and shorthand notations, see <link linkend="HDRWQ567">The | |
1030 | AFS ACL Permissions</link>.</para> | |
1031 | ||
1032 | <para>On a single command line, you can combine user and group entries. You can also use individual letters in some | |
1033 | pairs and the shorthand notations in other pairs, but cannot combine letters and shorthand notation within a single | |
1034 | pair.</para> | |
1035 | </listitem> | |
1036 | </varlistentry> | |
1037 | </variablelist> | |
1038 | </listitem> | |
1039 | </orderedlist> | |
1040 | ||
1041 | <para>Either of the following examples grants user <emphasis role="bold">pat</emphasis> the <emphasis role="bold">r</emphasis> | |
1042 | (<emphasis role="bold">read</emphasis>) and <emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) | |
1043 | permissions on the ACL of the <emphasis role="bold">notes</emphasis> subdirectory in the issuer's home directory. They | |
1044 | illustrate how it is possible to omit the <emphasis role="bold">-dir</emphasis> and <emphasis role="bold">-acl</emphasis> | |
1045 | switches when you name only one directory.</para> | |
1046 | ||
1047 | <programlisting> | |
1048 | % <emphasis role="bold">fs sa ~/notes pat rl</emphasis> | |
1049 | % <emphasis role="bold">fs sa ~/notes pat read</emphasis> | |
1050 | </programlisting> | |
1051 | ||
1052 | <para>The following example edits the ACL for the current working directory. It removes the entry for the <emphasis | |
1053 | role="bold">system:anyuser</emphasis> group, and adds two entries: one grants all permissions except <emphasis | |
1054 | role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) to the members of the <emphasis | |
1055 | role="bold">terry:colleagues</emphasis> group and the other grants the <emphasis role="bold">r</emphasis> (<emphasis | |
1056 | role="bold">read</emphasis>) and <emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) permissions to | |
1057 | the <emphasis role="bold">system:authuser</emphasis> group. The command appears on two lines here only for legibility.</para> | |
1058 | ||
1059 | <programlisting> | |
1060 | % <emphasis role="bold">fs sa -dir . -acl system:anyuser none terry:colleagues write \ | |
1061 | system:authuser rl</emphasis> | |
1062 | </programlisting> | |
1063 | ||
1064 | <indexterm> | |
1065 | <primary>fs commands</primary> | |
1066 | ||
1067 | <secondary>setacl</secondary> | |
1068 | ||
1069 | <tertiary>with -negative flag</tertiary> | |
1070 | </indexterm> | |
1071 | ||
1072 | <indexterm> | |
1073 | <primary>commands</primary> | |
1074 | ||
1075 | <secondary>fs setacl</secondary> | |
1076 | ||
1077 | <tertiary>with -negative flag</tertiary> | |
1078 | </indexterm> | |
1079 | ||
1080 | <indexterm> | |
1081 | <primary>creating</primary> | |
1082 | ||
1083 | <secondary>ACL entry in negative permissions section</secondary> | |
1084 | </indexterm> | |
1085 | ||
1086 | <indexterm> | |
1087 | <primary>adding</primary> | |
1088 | ||
1089 | <secondary>ACL entry</secondary> | |
1090 | ||
1091 | <tertiary>negative permissions</tertiary> | |
1092 | </indexterm> | |
1093 | ||
1094 | <indexterm> | |
1095 | <primary>denying</primary> | |
1096 | ||
1097 | <secondary>file access with negative ACL entry</secondary> | |
1098 | </indexterm> | |
1099 | </sect2> | |
1100 | ||
1101 | <sect2 id="HDRWQ575"> | |
1102 | <title>To add, remove, or edit negative ACL permissions</title> | |
1103 | ||
1104 | <orderedlist> | |
1105 | <listitem> | |
1106 | <para>Verify that you have the <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission | |
1107 | on each directory for which you are editing the ACL. If necessary, issue the <emphasis role="bold">fs listacl</emphasis> | |
1108 | command, which is fully described in <link linkend="HDRWQ572">Displaying ACLs</link>. <programlisting> | |
1109 | % <emphasis role="bold">fs listacl</emphasis> [<<replaceable>dir/file path</replaceable>>] | |
1110 | </programlisting></para> | |
1111 | </listitem> | |
1112 | ||
1113 | <listitem> | |
1114 | <para>Issue the <emphasis role="bold">fs setacl</emphasis> command with the <emphasis role="bold">-negative</emphasis> | |
1115 | flag to edit entries in the negative permissions section of the ACL. To remove an entry, specify the <emphasis | |
1116 | role="bold">none</emphasis> shorthand as the permissions. If an ACL entry already exists for a user or group, the | |
1117 | permissions you specify completely replace those in the existing entry. <programlisting> | |
1118 | % <emphasis role="bold">fs setacl -dir</emphasis> <<replaceable>directory</replaceable>>+ <emphasis role="bold">-acl</emphasis> <<replaceable>access list entries</replaceable>>+ <emphasis | |
1119 | role="bold">-negative</emphasis> | |
1120 | </programlisting></para> | |
1121 | ||
1122 | <para>where</para> | |
1123 | ||
1124 | <variablelist> | |
1125 | <varlistentry> | |
1126 | <term><emphasis role="bold">sa</emphasis></term> | |
1127 | ||
1128 | <listitem> | |
1129 | <para>Is an acceptable alias for <emphasis role="bold">setacl</emphasis> (and <emphasis role="bold">seta</emphasis> | |
1130 | is the shortest acceptable abbreviation).</para> | |
1131 | </listitem> | |
1132 | </varlistentry> | |
1133 | ||
1134 | <varlistentry> | |
1135 | <term><emphasis role="bold">-dir</emphasis></term> | |
1136 | ||
1137 | <listitem> | |
1138 | <para>Names one or more directories to which to apply the negative ACL entries defined by the <emphasis | |
1139 | role="bold">-acl</emphasis> argument. Specify the read/write path to each directory, to avoid the failure that | |
1140 | results when you attempt to change a read-only volume. For a detailed description of acceptable values, see <link | |
1141 | linkend="HDRWQ574">To add, remove, or edit normal ACL permissions</link>.</para> | |
1142 | </listitem> | |
1143 | </varlistentry> | |
1144 | ||
1145 | <varlistentry> | |
1146 | <term><emphasis role="bold">-acl</emphasis></term> | |
1147 | ||
1148 | <listitem> | |
1149 | <para>Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate | |
1150 | the pairs, and the two parts of each pair, with one or more spaces. For a detailed description of acceptable values, | |
1151 | see <link linkend="HDRWQ574">To add, remove, or edit normal ACL permissions</link>. Keep in mind that the usual | |
1152 | meaning of each permission is reversed.</para> | |
1153 | </listitem> | |
1154 | </varlistentry> | |
1155 | ||
1156 | <varlistentry> | |
1157 | <term><emphasis role="bold">-negative</emphasis></term> | |
1158 | ||
1159 | <listitem> | |
1160 | <para>Places the entries defined by the <emphasis role="bold">-acl</emphasis> argument on the negative permissions | |
1161 | section of the ACL for each directory named by the <emphasis role="bold">-dir</emphasis> argument.</para> | |
1162 | </listitem> | |
1163 | </varlistentry> | |
1164 | </variablelist> | |
1165 | </listitem> | |
1166 | </orderedlist> | |
1167 | ||
1168 | <para>The following example denies user <emphasis role="bold">pat</emphasis> the <emphasis role="bold">w</emphasis> (<emphasis | |
1169 | role="bold">write</emphasis>) and <emphasis role="bold">d</emphasis> (<emphasis role="bold">delete</emphasis>) permissions for | |
1170 | the <emphasis role="bold">project</emphasis> subdirectory of the current working directory.</para> | |
1171 | ||
1172 | <programlisting> | |
1173 | % <emphasis role="bold">fs sa project pat wd -neg</emphasis> | |
1174 | </programlisting> | |
1175 | </sect2> | |
1176 | </sect1> | |
1177 | ||
1178 | <sect1 id="HDRWQ576"> | |
1179 | <title>Completely Replacing an ACL</title> | |
1180 | ||
1181 | <indexterm> | |
1182 | <primary>ACL</primary> | |
1183 | ||
1184 | <secondary>replacing all entries</secondary> | |
1185 | </indexterm> | |
1186 | ||
1187 | <indexterm> | |
1188 | <primary>ACL</primary> | |
1189 | ||
1190 | <secondary>clearing</secondary> | |
1191 | </indexterm> | |
1192 | ||
1193 | <indexterm> | |
1194 | <primary>replacing</primary> | |
1195 | ||
1196 | <secondary>all entries on ACL</secondary> | |
1197 | </indexterm> | |
1198 | ||
1199 | <indexterm> | |
1200 | <primary>erasing</primary> | |
1201 | ||
1202 | <secondary>all ACL entries</secondary> | |
1203 | </indexterm> | |
1204 | ||
1205 | <indexterm> | |
1206 | <primary>clearing</primary> | |
1207 | ||
1208 | <secondary>all ACL entries</secondary> | |
1209 | </indexterm> | |
1210 | ||
1211 | <indexterm> | |
1212 | <primary>removing</primary> | |
1213 | ||
1214 | <secondary>all ACL entries</secondary> | |
1215 | </indexterm> | |
1216 | ||
1217 | <para>It is sometimes simplest to clear an ACL completely before defining new permissions on it, for instance if the mix of | |
1218 | normal and negative permissions makes it difficult to understand how their interaction affects a user's access to the directory. | |
1219 | To clear an ACL completely while you define new entries, include the <emphasis role="bold">-clear</emphasis> flag on the | |
1220 | <emphasis role="bold">fs setacl</emphasis> command. When you include this flag, you can create entries on either the normal | |
1221 | permissions or the negative permissions section of the ACL, but not on both at once.</para> | |
1222 | ||
1223 | <para>Remember to create an entry that grants appropriate permissions to the directory's owner. The owner implicitly has the | |
1224 | <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission required to replace a deleted entry, | |
1225 | but the effects of a missing ACL entry (particularly the lack of the <emphasis role="bold">lookup</emphasis> permission) can be | |
1226 | so confusing that it becomes difficult for the owner to realize that the missing entry is causing the problems. <indexterm> | |
1227 | <primary>fs commands</primary> | |
1228 | ||
1229 | <secondary>setacl</secondary> | |
1230 | ||
1231 | <tertiary>with -clear flag</tertiary> | |
1232 | </indexterm> <indexterm> | |
1233 | <primary>commands</primary> | |
1234 | ||
1235 | <secondary>fs setacl</secondary> | |
1236 | ||
1237 | <tertiary>with -clear flag</tertiary> | |
1238 | </indexterm></para> | |
1239 | ||
1240 | <sect2 id="Header_645"> | |
1241 | <title>To replace an ACL completely</title> | |
1242 | ||
1243 | <orderedlist> | |
1244 | <listitem> | |
1245 | <para>Verify that you have the <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission | |
1246 | on each directory for which you are editing the ACL. If necessary, issue the <emphasis role="bold">fs listacl</emphasis> | |
1247 | command, which is fully described in <link linkend="HDRWQ572">Displaying ACLs</link>. <programlisting> | |
1248 | % <emphasis role="bold">fs listacl</emphasis> [<<replaceable>dir/file path</replaceable>>] | |
1249 | </programlisting></para> | |
1250 | </listitem> | |
1251 | ||
1252 | <listitem> | |
1253 | <para>Issue the <emphasis role="bold">fs setacl</emphasis> command with the <emphasis role="bold">-clear</emphasis> flag | |
1254 | to clear the ACL completely before setting either normal or negative permissions. Because you need to grant the owner of | |
1255 | the directory all permissions, it is better in most cases to set normal permissions at this point. <programlisting> | |
1256 | % <emphasis role="bold">fs setacl -dir</emphasis> <<replaceable>directory</replaceable>>+ <emphasis role="bold">-acl</emphasis> <<replaceable>access list entries</replaceable>>+ <emphasis | |
1257 | role="bold">-clear</emphasis> \ | |
1258 | [<emphasis role="bold">-negative</emphasis>] | |
1259 | </programlisting></para> | |
1260 | ||
1261 | <para>where</para> | |
1262 | ||
1263 | <variablelist> | |
1264 | <varlistentry> | |
1265 | <term><emphasis role="bold">sa</emphasis></term> | |
1266 | ||
1267 | <listitem> | |
1268 | <para>Is an acceptable alias for <emphasis role="bold">setacl</emphasis> (and <emphasis role="bold">seta</emphasis> | |
1269 | is the shortest acceptable abbreviation).</para> | |
1270 | </listitem> | |
1271 | </varlistentry> | |
1272 | ||
1273 | <varlistentry> | |
1274 | <term><emphasis role="bold">-dir</emphasis></term> | |
1275 | ||
1276 | <listitem> | |
1277 | <para>Names one or more directories to which to apply the negative ACL entries defined by the <emphasis | |
1278 | role="bold">-acl</emphasis> argument. Specify the read/write path to each directory, to avoid the failure that | |
1279 | results when you attempt to change a read-only volume. For a detailed description of acceptable values, see <link | |
1280 | linkend="HDRWQ574">To add, remove, or edit normal ACL permissions</link>.</para> | |
1281 | </listitem> | |
1282 | </varlistentry> | |
1283 | ||
1284 | <varlistentry> | |
1285 | <term><emphasis role="bold">-acl</emphasis></term> | |
1286 | ||
1287 | <listitem> | |
1288 | <para>Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate | |
1289 | the pairs, and the two parts of each pair, with one or more spaces. Remember to grant all permissions to the owner | |
1290 | of the directory. For a detailed description of acceptable values, see <link linkend="HDRWQ574">To add, remove, or | |
1291 | edit normal ACL permissions</link>.</para> | |
1292 | </listitem> | |
1293 | </varlistentry> | |
1294 | ||
1295 | <varlistentry> | |
1296 | <term><emphasis role="bold">-clear</emphasis></term> | |
1297 | ||
1298 | <listitem> | |
1299 | <para>Removes all entries from each ACL before creating the entries indicated by the <emphasis | |
1300 | role="bold">-acl</emphasis> argument.</para> | |
1301 | </listitem> | |
1302 | </varlistentry> | |
1303 | ||
1304 | <varlistentry> | |
1305 | <term><emphasis role="bold">-negative</emphasis></term> | |
1306 | ||
1307 | <listitem> | |
1308 | <para>Places the entries defined by the <emphasis role="bold">-acl</emphasis> argument on the negative permissions | |
1309 | section of each ACL.</para> | |
1310 | </listitem> | |
1311 | </varlistentry> | |
1312 | </variablelist> | |
1313 | </listitem> | |
1314 | </orderedlist> | |
1315 | </sect2> | |
1316 | </sect1> | |
1317 | ||
1318 | <sect1 id="HDRWQ577"> | |
1319 | <title>Copying ACLs Between Directories</title> | |
1320 | ||
1321 | <indexterm> | |
1322 | <primary>ACL</primary> | |
1323 | ||
1324 | <secondary>copying between directories</secondary> | |
1325 | </indexterm> | |
1326 | ||
1327 | <indexterm> | |
1328 | <primary>creating</primary> | |
1329 | ||
1330 | <secondary>ACL as copy of another</secondary> | |
1331 | </indexterm> | |
1332 | ||
1333 | <indexterm> | |
1334 | <primary>copying</primary> | |
1335 | ||
1336 | <secondary>ACL between directories</secondary> | |
1337 | </indexterm> | |
1338 | ||
1339 | <para>The <emphasis role="bold">fs copyacl</emphasis> command copies a source directory's ACL to one or more destination | |
1340 | directories. It does not affect the source ACL at all, but changes each destination ACL as follows: <itemizedlist> | |
1341 | <listitem> | |
1342 | <para>If an entry on the source ACL does not exist on the destination ACL, the command copies it to the destination | |
1343 | ACL.</para> | |
1344 | </listitem> | |
1345 | ||
1346 | <listitem> | |
1347 | <para>If an entry on the destination ACL does not also exist on the source ACL, the command does not remove it unless you | |
1348 | include the <emphasis role="bold">-clear</emphasis> flag to overwrite the destination ACL completely.</para> | |
1349 | </listitem> | |
1350 | ||
1351 | <listitem> | |
1352 | <para>If an entry is on both ACLs, the command changes the permissions on the destination ACL entry to match the source | |
1353 | ACL entry.</para> | |
1354 | </listitem> | |
1355 | </itemizedlist></para> | |
1356 | ||
1357 | <para><emphasis role="bold">Note for AFS/DFS Migration Toolkit users:</emphasis> If the machine is configured to enable AFS | |
1358 | users to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, then you can use the <emphasis role="bold">fs | |
1359 | copyacl</emphasis> command to copy ACLs between DFS files and directories also. The command includes <emphasis | |
1360 | role="bold">-id</emphasis> and <emphasis role="bold">-if</emphasis> flags for altering a DFS directory's Initial Container and | |
1361 | Initial Object ACLs as well as its regular ACL; see the <emphasis>OpenAFS/DFS Migration Toolkit Administration Guide and | |
1362 | Reference</emphasis>. You cannot copy ACLs between AFS and DFS directories, because they use different ACL formats. The | |
1363 | <emphasis role="bold">fs</emphasis> command interpreter ignores the <emphasis role="bold">-id</emphasis> and <emphasis | |
1364 | role="bold">-if</emphasis> flags if you include them when copying AFS ACLs. <indexterm> | |
1365 | <primary>fs commands</primary> | |
1366 | ||
1367 | <secondary>copyacl</secondary> | |
1368 | </indexterm><indexterm> | |
1369 | <primary>commands</primary> | |
1370 | ||
1371 | <secondary>fs copyacl</secondary> | |
1372 | </indexterm></para> | |
1373 | ||
1374 | <sect2 id="Header_647"> | |
1375 | <title>To copy an ACL between directories</title> | |
1376 | ||
1377 | <orderedlist> | |
1378 | <listitem> | |
1379 | <para>Verify that you have the <emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) permission on | |
1380 | the source ACL and the <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission on each | |
1381 | destination ACL. To identify the source directory by naming a file in it, you must also have the <emphasis | |
1382 | role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>) permission on the source ACL. If necessary, issue the | |
1383 | <emphasis role="bold">fs listacl</emphasis> command, which is fully described in <link linkend="HDRWQ572">Displaying | |
1384 | ACLs</link>. <programlisting> | |
1385 | % <emphasis role="bold">fs listacl</emphasis> [<<replaceable>dir/file path</replaceable>>] | |
1386 | </programlisting></para> | |
1387 | </listitem> | |
1388 | ||
1389 | <listitem> | |
1390 | <para>Issue the <emphasis role="bold">fs copyacl</emphasis> command to copy a source ACL to the ACL | |
1391 | on one or more destination directories. (The command appears here on two lines only for legibility.) <programlisting> | |
1392 | % <emphasis role="bold">fs copyacl -fromdir</emphasis> <<replaceable>source directory</replaceable>> <emphasis role="bold">-todir</emphasis> <<replaceable>destination directory</replaceable>>+ \ | |
1393 | [<emphasis role="bold">-clear</emphasis>] | |
1394 | </programlisting></para> | |
1395 | ||
1396 | <para>where</para> | |
1397 | ||
1398 | <variablelist> | |
1399 | <varlistentry> | |
1400 | <term><emphasis role="bold">co</emphasis></term> | |
1401 | ||
1402 | <listitem> | |
1403 | <para>Is the shortest acceptable abbreviation for <emphasis role="bold">copyacl</emphasis>.</para> | |
1404 | </listitem> | |
1405 | </varlistentry> | |
1406 | ||
1407 | <varlistentry> | |
1408 | <term><emphasis role="bold">-fromdir</emphasis></term> | |
1409 | ||
1410 | <listitem> | |
1411 | <para>Names the source directory from which to copy the ACL. Partial pathnames are interpreted relative to the | |
1412 | current working directory. If this argument names a file, the ACL is copied from its directory.</para> | |
1413 | </listitem> | |
1414 | </varlistentry> | |
1415 | ||
1416 | <varlistentry> | |
1417 | <term><emphasis role="bold">-todir</emphasis></term> | |
1418 | ||
1419 | <listitem> | |
1420 | <para>Names each destination directory to which to copy the source ACL. Partial pathnames are interpreted relative | |
1421 | to the current working directory. Filenames are not acceptable.</para> | |
1422 | ||
1423 | <para>Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a | |
1424 | read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the | |
1425 | pathname's second level (for example, <emphasis role="bold">/afs/.example.com</emphasis>). For further discussion of the | |
1426 | concept of read/write and read-only paths through the filespace, see <link linkend="HDRWQ209">The Rules of Mount | |
1427 | Point Traversal</link>.</para> | |
1428 | </listitem> | |
1429 | </varlistentry> | |
1430 | ||
1431 | <varlistentry> | |
1432 | <term><emphasis role="bold">-clear</emphasis></term> | |
1433 | ||
1434 | <listitem> | |
1435 | <para>Completely overwrites each destination directory's ACL with the source ACL.</para> | |
1436 | </listitem> | |
1437 | </varlistentry> | |
1438 | </variablelist> | |
1439 | </listitem> | |
1440 | </orderedlist> | |
1441 | ||
1442 | <para>The following example copies the ACL from the current working directory's <emphasis role="bold">notes</emphasis> | |
1443 | subdirectory to the <emphasis role="bold">plans</emphasis> subdirectory. The issuer does not include the <emphasis | |
1444 | role="bold">-clear</emphasis> flag, so the entry for user <emphasis role="bold">pat</emphasis> remains on the <emphasis | |
1445 | role="bold">plans</emphasis> directory's ACL although there is no corresponding entry on the <emphasis | |
1446 | role="bold">notes</emphasis> directory's ACL.</para> | |
1447 | ||
1448 | <programlisting> | |
1449 | % <emphasis role="bold">fs la notes plans</emphasis> | |
1450 | Access list for notes is | |
1451 | Normal permissions: | |
1452 | terry rlidwka | |
1453 | smith rl | |
1454 | jones rl | |
1455 | Access list for plans is | |
1456 | Normal permissions: | |
1457 | terry rlidwk | |
1458 | pat rlidwk | |
1459 | % <emphasis role="bold">fs copyacl notes plans</emphasis> | |
1460 | % <emphasis role="bold">fs la notes plans</emphasis> | |
1461 | Access list for notes is | |
1462 | Normal permissions: | |
1463 | terry rlidwka | |
1464 | smith rl | |
1465 | jones rl | |
1466 | Access list for plans is | |
1467 | Normal permissions: | |
1468 | terry rlidwka | |
1469 | pat rlidwk | |
1470 | smith rl | |
1471 | jones rl | |
1472 | </programlisting> | |
1473 | ||
1474 | <indexterm> | |
1475 | <primary>ACL</primary> | |
1476 | ||
1477 | <secondary>removing obsolete AFS IDs</secondary> | |
1478 | </indexterm> | |
1479 | ||
1480 | <indexterm> | |
1481 | <primary>removing</primary> | |
1482 | ||
1483 | <secondary>obsolete AFS IDs from ACL</secondary> | |
1484 | </indexterm> | |
1485 | ||
1486 | <indexterm> | |
1487 | <primary>AFS UID</primary> | |
1488 | ||
1489 | <secondary>removing obsolete from ACL</secondary> | |
1490 | </indexterm> | |
1491 | ||
1492 | <indexterm> | |
1493 | <primary>AFS GID</primary> | |
1494 | ||
1495 | <secondary>removing obsolete from ACL</secondary> | |
1496 | </indexterm> | |
1497 | ||
1498 | <indexterm> | |
1499 | <primary>ACL</primary> | |
1500 | ||
1501 | <secondary>cleaning</secondary> | |
1502 | </indexterm> | |
1503 | </sect2> | |
1504 | </sect1> | |
1505 | ||
1506 | <sect1 id="HDRWQ579"> | |
1507 | <title>Removing Obsolete AFS IDs from ACLs</title> | |
1508 | ||
1509 | <para>When you remove a user or group entry from the Protection Database, the <emphasis role="bold">fs listacl</emphasis> | |
1510 | command displays the user's AFS UID (or group's AFS GID) in ACL entries, rather than the name. In the following example, user | |
1511 | <emphasis role="bold">terry</emphasis> has an ACL entry for the group <emphasis role="bold">terry:friends</emphasis> (AFS GID | |
1512 | -567) on her home directory in the Example Corporation cell, and then removes the group from the Protection Database.</para> | |
1513 | ||
1514 | <programlisting> | |
1515 | % <emphasis role="bold">fs listacl /afs/example.com/usr/terry</emphasis> | |
1516 | Access list for /afs/example.com/usr/terry is | |
1517 | Normal permissions: | |
1518 | terry:friends rlik | |
1519 | system:anyuser l | |
1520 | terry rlidwka | |
1521 | % <emphasis role="bold">pts delete terry:friends</emphasis> | |
1522 | % <emphasis role="bold">fs listacl /afs/example.com/usr/terry</emphasis> | |
1523 | Access list for /afs/example.com/usr/terry is | |
1524 | Normal permissions: | |
1525 | -567 rlik | |
1526 | system:anyuser l | |
1527 | terry rlidwka | |
1528 | </programlisting> | |
1529 | ||
1530 | <para>Leaving AFS IDs on ACLs serves no function, because the ID no longer corresponds to an active user or group. Furthermore, | |
1531 | 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 | |
1532 | actually intended for the previous possessor. (Reusing AFS IDs is not recommended precisely for this reason.)</para> | |
1533 | ||
1534 | <para>To remove obsolete AFS UIDs from ACLs, use the <emphasis role="bold">fs cleanacl</emphasis> command. <indexterm> | |
1535 | <primary>commands</primary> | |
1536 | ||
1537 | <secondary>fs cleanacl</secondary> | |
1538 | </indexterm> <indexterm> | |
1539 | <primary>fs commands</primary> | |
1540 | ||
1541 | <secondary>cleanacl</secondary> | |
1542 | </indexterm></para> | |
1543 | ||
1544 | <sect2 id="Header_649"> | |
1545 | <title>To clean obsolete AFS IDs from an ACL</title> | |
1546 | ||
1547 | <orderedlist> | |
1548 | <listitem> | |
1549 | <para>Verify that you have the <emphasis role="bold">a</emphasis> (<emphasis role="bold">administer</emphasis>) permission | |
1550 | on each directory for which you are cleaning the ACL. If necessary, issue the <emphasis role="bold">fs listacl</emphasis> | |
1551 | command, which is fully described in <link linkend="HDRWQ572">Displaying ACLs</link>. <programlisting> | |
1552 | % <emphasis role="bold">fs listacl</emphasis> [<<replaceable>dir/file path</replaceable>>] | |
1553 | </programlisting></para> | |
1554 | </listitem> | |
1555 | ||
1556 | <listitem> | |
1557 | <para>Issue the <emphasis role="bold">fs cleanacl</emphasis> command to remove entries for obsolete AFS IDs. | |
1558 | <programlisting> | |
1559 | % <emphasis role="bold">fs cleanacl</emphasis> [<<replaceable>dir/file path</replaceable>>+] | |
1560 | </programlisting></para> | |
1561 | ||
1562 | <para>where</para> | |
1563 | ||
1564 | <variablelist> | |
1565 | <varlistentry> | |
1566 | <term><emphasis role="bold">cl</emphasis></term> | |
1567 | ||
1568 | <listitem> | |
1569 | <para>Is the shortest acceptable abbreviation of <emphasis role="bold">cleanacl</emphasis>.</para> | |
1570 | </listitem> | |
1571 | </varlistentry> | |
1572 | ||
1573 | <varlistentry> | |
1574 | <term><emphasis role="bold">dir/file path</emphasis></term> | |
1575 | ||
1576 | <listitem> | |
1577 | <para>Names each directory for which to clean the ACL. If this argument names a file, its directory's ACL is | |
1578 | cleaned. Omit this argument to clean the current working directory's ACL.</para> | |
1579 | ||
1580 | <para>Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a | |
1581 | read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the | |
1582 | pathname's second level (for example, <emphasis role="bold">/afs/.example.com</emphasis>). For further discussion of the | |
1583 | concept of read/write and read-only paths through the filespace, see <link linkend="HDRWQ209">The Rules of Mount | |
1584 | Point Traversal</link>.</para> | |
1585 | ||
1586 | <para>You can also use the following notation on its own or as part of a pathname:</para> | |
1587 | ||
1588 | <variablelist> | |
1589 | <varlistentry> | |
1590 | <term><emphasis role="bold">.</emphasis></term> | |
1591 | ||
1592 | <listitem> | |
1593 | <para>(A single period). If used by itself, cleans the current working directory's ACL.</para> | |
1594 | </listitem> | |
1595 | </varlistentry> | |
1596 | ||
1597 | <varlistentry> | |
1598 | <term><emphasis role="bold">..</emphasis></term> | |
1599 | ||
1600 | <listitem> | |
1601 | <para>(Two periods). If used by itself, cleans the ACL on the current working directory's parent | |
1602 | directory.</para> | |
1603 | </listitem> | |
1604 | </varlistentry> | |
1605 | ||
1606 | <varlistentry> | |
1607 | <term><emphasis role="bold">*</emphasis></term> | |
1608 | ||
1609 | <listitem> | |
1610 | <para>(The asterisk). Cleans the ACL of each of the subdirectories in the current working directory. However, | |
1611 | if you use the asterisk and there are obsolete AFS IDs on any directory's ACL, the following error message | |
1612 | appears for every file in the directory: <programlisting> | |
1613 | fs: 'filename': Not a directory | |
1614 | </programlisting></para> | |
1615 | </listitem> | |
1616 | </varlistentry> | |
1617 | </variablelist> | |
1618 | </listitem> | |
1619 | </varlistentry> | |
1620 | </variablelist> | |
1621 | </listitem> | |
1622 | </orderedlist> | |
1623 | ||
1624 | <para>If there are obsolete AFS IDs on a directory, the command interpreter displays its cleaned ACL under the following | |
1625 | header.</para> | |
1626 | ||
1627 | <programlisting> | |
1628 | Access list for directory is now | |
1629 | </programlisting> | |
1630 | ||
1631 | <para>If a directory's ACL has no obsolete AFS IDs on it, the following message appears for each.</para> | |
1632 | ||
1633 | <programlisting> | |
1634 | Access list for directory is fine. | |
1635 | </programlisting> | |
1636 | </sect2> | |
1637 | </sect1> | |
1638 | ||
1639 | <sect1 id="HDRWQ580"> | |
1640 | <title>How AFS Interprets the UNIX Mode Bits</title> | |
1641 | ||
1642 | <indexterm> | |
1643 | <primary>UNIX</primary> | |
1644 | ||
1645 | <secondary>mode bits, interpretation in AFS</secondary> | |
1646 | </indexterm> | |
1647 | ||
1648 | <indexterm> | |
1649 | <primary>UFS</primary> | |
1650 | ||
1651 | <secondary>mode bits, interpretation in AFS</secondary> | |
1652 | </indexterm> | |
1653 | ||
1654 | <indexterm> | |
1655 | <primary>mode bits (UNIX)</primary> | |
1656 | ||
1657 | <secondary>interpretation in AFS</secondary> | |
1658 | </indexterm> | |
1659 | ||
1660 | <para>Although AFS uses ACLs to protect file data rather than the mode bits that UFS uses, it does not ignore the mode bits | |
1661 | entirely. When you issue the <emphasis role="bold">chmod</emphasis> command on an AFS file or directory, AFS changes the bits | |
1662 | appropriately. To change a file's mode bits, you must have the AFS <emphasis role="bold">w</emphasis> (<emphasis | |
1663 | role="bold">write</emphasis>) permission on the ACL of the file's directory. To change a directory's mode bits, you must have | |
1664 | the <emphasis role="bold">d</emphasis> (<emphasis role="bold">delete</emphasis>), <emphasis role="bold">i</emphasis> (<emphasis | |
1665 | role="bold">insert</emphasis>), and <emphasis role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) permissions on | |
1666 | its ACL.</para> | |
1667 | ||
1668 | <para>AFS also uses the UNIX mode bits as follows:</para> | |
1669 | ||
1670 | <itemizedlist> | |
1671 | <listitem> | |
1672 | <para>It uses the initial bit to determine the element's type. This is the bit that appears first in the output from the | |
1673 | <emphasis role="bold">ls -l</emphasis> command and shows the hyphen (<emphasis role="bold">-</emphasis>) for a file or the | |
1674 | letter <emphasis role="bold">d</emphasis> for a directory.</para> | |
1675 | </listitem> | |
1676 | ||
1677 | <listitem> | |
1678 | <para>It does not use any of the mode bits on a directory.</para> | |
1679 | </listitem> | |
1680 | ||
1681 | <listitem> | |
1682 | <para>For a file, the first (owner) set of bits interacts with the ACL entries that apply to the file in the following way: | |
1683 | <itemizedlist> | |
1684 | <listitem> | |
1685 | <para>If the first <emphasis role="bold">r</emphasis> mode bit is not set, no one (including the owner) can read the | |
1686 | file, no matter what permissions they have on the ACL. If the bit is set, users also need the <emphasis | |
1687 | role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>) and <emphasis role="bold">l</emphasis> permissions on | |
1688 | the ACL of the file's directory to read the file.</para> | |
1689 | </listitem> | |
1690 | ||
1691 | <listitem> | |
1692 | <para>If the first <emphasis role="bold">w</emphasis> mode bit is not set, no one (including the owner) can modify the | |
1693 | file. If the <emphasis role="bold">w</emphasis> bit is set, users also need the <emphasis role="bold">w</emphasis> and | |
1694 | <emphasis role="bold">l</emphasis> permissions on the ACL of the file's directory to modify the file.</para> | |
1695 | </listitem> | |
1696 | ||
1697 | <listitem> | |
1698 | <para>There is no ACL permission directly corresponding to the <emphasis role="bold">x</emphasis> mode bit, but to | |
1699 | execute a file stored in AFS, the user must also have the <emphasis role="bold">r</emphasis> and <emphasis | |
1700 | role="bold">l</emphasis> permissions on the ACL of the file's directory.</para> | |
1701 | </listitem> | |
1702 | </itemizedlist></para> | |
1703 | </listitem> | |
1704 | </itemizedlist> | |
1705 | </sect1> | |
1706 | </chapter> |