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

[Jeffrey Hutzelman]

--On Monday, February 07, 2011 02:04:46 PM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> In the dropbox case the client has no need to read anything from the
> server.  It should only be creating new files.

So, the thing that everyone seems to be forgetting is that the client 
provides a cached view on the contents of the server, and that parts of a 
file may disappear from the client's cache because the space is needed for 
something else.

The expected semantics of dropboxes are that I can open a new file and then 
write and read back as much as I want until I close it.  A simple file copy 
won't need to read back, but some other applications might.  If the file in 
question is large, or there is a lot of cache pressure, the client may be 
forced to write some dirty buffers and remove them from the cache even 
though the file has not been closed.  Clients do that depending on the fact 
that they can always read the flushed chunks back from the fileserver if 
the application references them again.





> If the Unix CM is reading beyond the end of file as part of preparing a
> chunk to be written, that sounds like a bug to me.

Who said anything about reading beyond EOF?
If you write to part of a chunk, the CM must first ensure it has an 
up-to-date copy of that chunk in the cache.

>> 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.
>
> The write will never fail.

Unless it requires reading back a chunk first, which fails because the 
server won't let you read a chunk back.

-- Jeff