From: Andrew Deason Date: Thu, 17 Feb 2011 20:33:07 +0000 (-0600) Subject: Document dropbox permissions X-Git-Tag: openafs-devel-1_7_1~913 X-Git-Url: https://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=9c7c6a2ca5c45367d1a8ed1710a4c99f8e3c5f6b Document dropbox permissions Document the behavior and potential problems with granting 'il' rights to create dropboxes. Do this in the manpage for 'fs setacl' and chapter 4 of the User Guide. Change-Id: Ic4e8ee016290080d78037a5c2c3802ce4e2e342c Reviewed-on: http://gerrit.openafs.org/3977 Tested-by: BuildBot Reviewed-by: Derrick Brashear --- diff --git a/doc/man-pages/pod1/fs_setacl.pod b/doc/man-pages/pod1/fs_setacl.pod index 17e8574..cbe0e4d 100644 --- a/doc/man-pages/pod1/fs_setacl.pod +++ b/doc/man-pages/pod1/fs_setacl.pod @@ -168,6 +168,11 @@ It is acceptable to mix entries that combine the individual letters with entries that use the shorthand words, but not use both types of notation within an individual pairing of user or group and permissions. +Granting the C (lookup) and C (insert) permissions without +granting the C (write) and/or C (read) permissions is a special +case, and grants rights approrpriate for "dropbox" directories. See the +L section for details. + If setting ACLs on a pathname in DFS filespace, see the DFS documentation for the proper format and acceptable values for DFS ACL entries. @@ -203,6 +208,38 @@ ignored. =back +=head1 DROPBOXES + +If an accessing user has the C (read) and C (insert) permissions +on a directory, but not the C (write) and/or C (read) permissions, +the user is implicitly granted the ability to write and/or read any file +they create in that directory, until they close the file. This is to +allow "dropbox"-style directories to exist, where users can deposit +files, but cannot modify them later nor can they modify or read any +files deposited in the directory by other users. + +Note, however, that the dropbox functionality is not perfect. The +fileserver does not have knowledge of when a file is opened or closed on +the client, and so the fileserver always allows an accessing user to +read or write to a file in a "dropbox" directory if they own the file. +While the client prevents the user from reading or modifying their +deposited file later, this is not enforced on the fileserver, and so +should not be relied on for security. + +Additionally, if "dropbox" permissions are granted to C, +unauthenticated users may deposit files in the directory. If an +unauthenticated user deposits a file in the directory, the new file will +be owned by the unauthenticated user ID, and is thus potentially +modifiable by anyone. + +In an effort to try and reduce accidentally publicizing private data, the +fileserver may refuse read requests for "dropbox" files from unauthenticated +users. As a result, depositing files as an unauthenticated user may arbitrarily +fail if C has been granted dropbox permissions. While this +should be rare, it is not completely preventable, and so for this reason +relying on unauthenticated users to be able to deposit files in a dropbox is +B. + =head1 EXAMPLES The following example adds two entries to the C section of diff --git a/doc/xml/UserGuide/auusg007.xml b/doc/xml/UserGuide/auusg007.xml index 82a4ffa..2408f97 100644 --- a/doc/xml/UserGuide/auusg007.xml +++ b/doc/xml/UserGuide/auusg007.xml @@ -448,6 +448,40 @@ the ACLs on DFS directories and files that you own. However, DFS uses a slightly different set of permissions and a different syntax for ACL entries. See the DFS documentation or ask your system administrator. + + + Dropbox Permissions + + If a user or group is granted the l (lookup) and + i (insert) permissions, but not the r (read) and/or + w (write) permissions, this is commonly referred to + as a "dropbox" for that user or group. What this means is that that user + or group may deposit files in the directory, but they may not read or + modify their file later, nor any other file in the directory. + + Know, however, that some of these restrictions are enforced on the + client and not on the fileserver, and so should not be relied on for + security. In particular, the fileserver does not know when a file is + opened or closed on the client, and and so read and write permissions are + granted to any user with "dropbox" permissions that owns the accessed + file. + + Additionally, granting "dropbox" permissons to system:anyuser raises additional problems, if you + want the dropbox to work for unauthenticated users. Any file deposited by + an unauthenticated user will be owned by the unauthenticated user ID, and + so would be readable and modifiable by anyone. In order to try and + prevent accidentally revealing private information, the fileserver does + not grant the implicit read permission to unauthenticated users, even if + they have dropbox permissions. This may cause depositing files as an + unauthenticated user to arbitrarily fail, and so you should not depend on + granting dropbox permissions to unauthenticated users to work + reliably. +