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<l> (lookup) and C<i> (insert) permissions without
+granting the C<w> (write) and/or C<r> (read) permissions is a special
+case, and grants rights approrpriate for "dropbox" directories. See the
+L<DROPBOXES> 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.
=back
+=head1 DROPBOXES
+
+If an accessing user has the C<l> (read) and C<i> (insert) permissions
+on a directory, but not the C<w> (write) and/or C<r> (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<system:anyuser>,
+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<system:anyuser> 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<NOT RECOMMENDED>.
+
=head1 EXAMPLES
The following example adds two entries to the C<Normal rights> section of
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.</para>
</sect2>
+
+ <sect2>
+ <title>Dropbox Permissions</title>
+
+ <para>If a user or group is granted the <emphasis
+ role="bold">l</emphasis> (<emphasis role="bold">lookup</emphasis>) and
+ <emphasis role="bold">i</emphasis> (<emphasis
+ role="bold">insert</emphasis>) permissions, but not the <emphasis
+ role="bold">r</emphasis> (<emphasis role="bold">read</emphasis>) and/or
+ <emphasis role="bold">w</emphasis> (<emphasis
+ role="bold">write</emphasis>) 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.</para>
+
+ <para>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.</para>
+
+ <para>Additionally, granting "dropbox" permissons to <emphasis
+ role="bold">system:anyuser</emphasis> 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.</para>
+ </sect2>
</sect1>
<sect1 id="HDRWQ50">