On 2/7/2011 11:54 AM, Andrew Deason wrote: > On Mon, 7 Feb 2011 11:02:18 -0500 > Derrick Brashear <[email protected]> wrote: > >> The effect of the "or be owner and have insert access" is to allow >> readback if for some reason you need to pull back from the server in >> the process of writing something out for insert. In an "atomic write" >> world this would not be necessary, and >> in this world it is only dubiously so. > > If the client were improved to only write dirty bytes to the server, > this could be avoided, yes?
The goal here is to provide AFS with Insert semantics. Unfortunately, because the file server has no notion of an "open fid" / "close fid" operation there is no ability to permit read/write capabilities only to the client that created the file and only until the file is "closed" for the first time. Instead, AFS makes a compromise. The file server gives implicit permission to read and write the contents of any file to any user that has 'i' privilege provided that they are the 'owner' of the file. The clients *may* then provide better Insert semantics by tracking the file creation and first close locally. However, this is not a requirement of a client and in fact cannot be implemented in all clients. One side effect of this policy is that if "system:anyuser" is granted "il" permissions, then any one in the world is able to list the contents of the directory and read/write every file in that directory which was created by an anonymous user. >> In a directory which is system:anyuser li, this allows people to read >> previous submissions. This is probably undesirable. It's simple to >> avoid the problem this way, which the compromise that readback isn't >> possible. > > I think arbitrary reads of this sort are currently prevented via > client-side enforcement, right? So it would be difficult to do that > accidentally. The MacOS X client cannot enforce this restriction and any user can modify any other client to remove this restriction. As a result, it is not sufficient to rely on the client. >> Ignoring the broader question of "do we really want the readback >> ever", comments on this revision? > > I think we'd need to advertise that s:anyuser dropboxes may not always > work as expected, if you're depending on anonymous inserters. This problem is not new and has been well-known in the AFS community for quite some time. The "What are dropboxes?" section (2.22) of the AFS FAQ: Using AFS page includes the following: "When the ACL on a directory is set to 'irl', this creates what is called a 'dropbox'. In theory, users should be able to deposit files in the directory, but not modify them once deposited. "In practice, the 'not modify them once deposited' part is not enforced by the fileserver; only the OpenAFS client enforces this restriction. Thus, you should not depend on this for security. "Also, note that system:anyuser=irl has additional problems: because dropbox semantics are based on pts identities (see question 2.21), the fileserver cannot distinguish between two unauthenticated users. So, not only can a user come back days later and modify the 'dropped' file, but any user can modify a file dropped by an unauthenticated user, at any time." Unfortunately, this is not documented either as part of the "fs setacl" page or in the Adminstrators Guide. My personal opinion is that anonymous users should not be permitted to read from a dropbox file owned by anonymous unless the "r" right is explicitly set. If the "r" right is set for system:anyuser, then the administrator has made an explicit decision to permit those files to be read after they are deposited. There is nothing we can do to prevent clients from writing to or over pre-existing files in this case from the perspective of the file server. I think it would also be worth-while to have a file server option that disables "i" for anonymous in its entirety. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
