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

[Derrick Brashear]

Derrick

On Feb 7, 2011, at 6:36 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> --On Monday, February 07, 2011 02:04:46 PM -0500 Jeffrey Altman <jaltman@s=
ecure-endpoints.com> wrote:
>=20
>> In the dropbox case the client has no need to read anything from the
>> server.  It should only be creating new files.
>=20
> So, the thing that everyone seems to be forgetting is that the client prov=
ides a cached view on the contents of the server, and that parts of a file m=
ay disappear from the client's cache because the space is needed for somethi=
ng else.
>=20
> The expected semantics of dropboxes are that I can open a new file and the=
n write and read back as much as I want until I close it.  A simple file cop=
y won't need to read back, but some other applications might.  If the file i=
n question is large, or there is a lot of cache pressure, the client may be f=
orced 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 t=
hey can always read the flushed chunks back from the fileserver if the appli=
cation references them again.
>=20
>=20
>=20

Some compromise is needed here for the anonymous case. This is the best one I=
 can conceive.

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

Either there was cache pressure (I care) or multiple writers to a single ins=
ert (don't care).
Otherwise, LocalHero...

>>> 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.
>>>=20
>>> I'm not saying that's necessarily a big problem, but it is a new thing
>>> that users should be made aware of.
>>=20
>> The write will never fail.
>=20
> Unless it requires reading back a chunk first, which fails because the ser=
ver won't let you read a chunk back.
>=20

The write doesn't require it. Someone else may require it to get to the poin=
t of letting you write, but the write doesn't care. It will write.