* bbackde at googlemail.com <bbackde at googlemail.com> [2007-09-25 17:29:47]:
> > Also, if the filesystem is readonly, you *will* need to use FileHash instead > > of TestDDA. > > This comment let me start thinking about the TestDDA design. Because > if the directory is read-only, the client have to handle the node > error (node cannot write the file) and the client must restart the > request. This is complicated and maybe confusing. The following > proposal tries to deal with this. I hope it is well thought. > Well, I think that the current one is well thought... See below limitations of your approach : > ------------------------------------------------ > > Proposal for a alternative implementation for TestDDA > > Reason for a new proposal: > The current TestDDA implementation requires the client to implement > more things than really > needed. This proposal makes it easier for clients because its a simple > question-and-answer > game with the node. The node sends the right 'questions' to the > client, because he knows what > to ask. This allows easy-to-implement stateless clients. > > If needed, I could explain the advantages for clients in more detail. > But I think if you compare the existing implementation of TestDDA with > this proposal you > encounter that this proposal is a more consistent implementation. Btw > this handles multiple concurrent > TestDDA requests (each request is tied to a ClientGET or ClientPUT). > > One does not fits all, so I think both implementations are useful for > the one or the other client. > This proposal is for clients that want to send a request, and handle > all following messages > in a different part of the code. They do not remember the original > send request, so its hard > for them to resend the request on failure. > > The following proposal is fully node driven, making the handling > easier for clients (e.g. the > decision if a filehash must be send is done by the node, because only > he knows if he can write the > required file to the target directory or if this is already denied > (read-only directory). > > Note: this new impl must be enabled using a new parameter on > ClientPUT/ClientGET. The is no need > to change existing clients. > > For each follow-on message the identifier that the client sent with > the first request is used, > because this messages belong to the same client request. > > ClientPUT: > ----------- > - client sends ClientPUT to node, with new parameter indicating to use > the new testdda impl > (node now needs to know if client is allowed to READ from the > directory where the file resides) > - node checks if the current socket is already authenticated to READ > from the directory It's not because you're allowed to read /etc/passwd and you sent the node its filehash that you should be allowed to read everything in /etc... (Maybe I'm missunderstanding what you're proposing) > - if YES, do the ClientPUT > - if NO (proceed as in current TestDDA implementation): > - node tries to create a new file with random content in the directory > - if OK, send message to client asking to read this new file and > return the content for verification > - if NOT OK, send message to client asking for a filehash of this file Nothing prevents clients from sending FileHash every time... > (OR maybe for a hash of a part of the file! much lesser resource > consumption. consider big files on > network shares or on DVDs! But this may by more insecure.) We have already discussed asking for hashes of parts of files; We can't do that. I can predict most of your /etc/shadow ; shall I be allowed to upload it ? If I dunno about the part you're asking can't I ask again 'til you ask me for a part I know ? 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/20070925/48624e0d/attachment.pgp>
