[OpenAFS-devel] Re: safe dropboxing in an anonymous world

[Andrew Deason]

On Mon, 07 Feb 2011 12:52:14 -0500
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> > 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.

...and what does this have to do with the quoted part of my message? If
you change the client to not need to write to the server in chunk-sized
bites, the client does not need to read any data from the server in
order to perform dropbox semantics, because we can always just write the
data to the fileserver as the application writes data, without needing
to re-read anything. Is this correct?

I'm just saying, if the not-recommended s:anyuser case sometimes breaks
as a result of this, it is not intrinsic. We can modify the client to
make it work.

> 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:

The general problem, yes. But the text you are referencing treats it as
a security/visibility problem. The change Derrick is talking about
introduces a new problem where the write to the dropbox file could
potentially fail, making the mechanism effectively break depending on
the use case.

I'm not saying that's necessarily a big problem, but it is a new thing
that users should be made aware of.

> I think it would also be worth-while to have a file server option that
> disables "i" for anonymous in its entirety.

Such as gerrit 217?

-- 
Andrew Deason
adeason@sinenomine.net