* Matthew Toseland <[EMAIL PROTECTED]> [2007-04-12 18:16:26]: > Okay, in summary:
Almost everything described below has been implemented in r12615 and prior that... check it :) Ok, I got rid of TestFileAccess messages. > > 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 <[EMAIL PROTECTED]> [2007-04-12 15:38:35]: > > > > > On Thu, Apr 12, 2007 at 02:26:38PM +0200, Florent Daignière (NextGen$) > > > wrote: > > > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [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$
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
