Okay, in summary: WRITE ACCESS ------------
Write access has to be per directory. The reason for this is that we cannot write to an existing file created by the client: We have to write to a temporary file in the same dir and then rename over the target, to avoid symlink attacks. Thus the directory-based TestDDA code works pretty well for this (sorry I still haven't read it). READ ACCESS ----------- For directories where the node has write access, TestDDA can demonstrate that the client has read access. For directories where the node does not have write access, the easiest thing is simply to force the client to use UploadFrom=direct. Later on we may provide an alternate mechanism, such as a challenge to hash the file with a certain salt, or a request for specific random offsets from the file. (The whole purpose of DDA is to save disk space). ERROR CODES ----------- Because clients need backwards compatibility, they may want to just submit the ClientGet or ClientPut, and if they get an error message, respond to it by doing a TestDDA. If the node gets a request to upload a file, (once this mechanism is mandatory), it should return an error message requiring the client to either do a TestDDA or just upload the file directly. If we have already done a TestDDA and this has failed then there should be a different error code, and the client should upload the file directly. The client should not be able to distinguish between "the node can't see the directory at all" and "the node can't create a file in the directory" when doing TestDDA. TestFileAccessReply ------------------- I am not convinced that this is useful. It is not a simple "are we on the same machine" test because there are many cases where there are partially shared filesystems on different machines. If the file does exist, we cannot write to it (that is one of our security precautions, maybe it should be revisited). If it doesn't, it is the directory which we are querying, not the file, and the only way to be sure we can write it is to do a full TestDDA. So it seems a confusing API to me, and possibly one that can be exploited to leak information. It might be useful to be able to check the status of previous TestDDA's, but I'm not convinced that being able to verify that the node can read from / write to a specific file is useful. What is the specific use case here? A client which only wants to show files which both the node and the client can read? There's no point, just show what the client can read, and upload directly if necessary. On Thu, Apr 12, 2007 at 04:47:46PM +0200, Florent Daigni?re (NextGen$) wrote: > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-04-12 15:38:35]: > > > On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daigni?re (NextGen$) > > wrote: > > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-12 > > > 14:06:28]: > > > > > > > I looked over your source, but where is the point when the node READS > > > > the file written by the client? It looks like the readFile is created > > > > by the node? > > > > > > > > Did I misunderstand this? > > > > > It's a variable naming missundersting: readFile is the file the node > writes and the client reads. > > > > Yes, "known issue" ... in the final version of the protocol the client > > > will choose the filename and the node will return if it can read from > > > it or not (assuming the file isn't empty). > > > > Why would the filename be created by the client? > > > > I thought the protocol was that the node writes a file which the client > > must read, then it tells the client to write a specific block of data to > > a specific file which the client must create. > > That's how it's implemented at the moment but it sucks... If you want > for instance to be able to use DDA (even read access only) on a directory > the node hasn't write access to it won't work as the node won't be able to > write the file the client is supposed to read. > > I have created and documented two new messages : TestFileAccessQuery and > TestFileAccessReply; Those will probably be usefull to figure out if the > node and the FCP client are on the same computer. > > I guess the solution will be to require the client to send us a hash of > the content he wants us to insert... but it requires both the client and > the node to compute the hash, and that obviously sucks :) > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070412/f377e416/attachment.pgp>
