[tahoe-dev] [tahoe-lafs] #690: raise size limit on furls

[tahoe-lafs]

#690: raise size limit on furls
------------------------------+---------------------------------------------
     Reporter:  adigeo        |       Owner:  warner
         Type:  defect        |      Status:  new   
     Priority:  critical      |   Milestone:  1.6.0 
    Component:  code-network  |     Version:  1.4.1 
   Resolution:                |    Keywords:        
Launchpad_bug:                |  
------------------------------+---------------------------------------------

Comment(by zooko):

 I should add that I really sympathize with Brian's desire for DoS-
 resistance in foolscap.  Foolscap FURLs are nice fine-grained capabilities
 -- you can give someone a FURL and thus give them the ability to invoke
 this or that method of this one object without also giving them any other
 abilities to affect your system.  It would be nice if every FURL didn't
 come with an implicit "... and the ability to drag your system to a halt
 (Windows) or cause arbitrary processes to be killed (Linux)" etc.

 I'm just not sure that it is practical.  Certainly I think Brian has erred
 by trying to make the limit close to the actual "probable max".  If he
 just goes through and multiplies every limit in the foolscap codebase by a
 factor of 100 then it would probably solve almost all of our problems.
 (The cost of that is that the malicious client can use up 100 times as
 much RAM if it maxes out every one of the fields it sends.)

 By the way, if you wanted to run network servers in a high-assurance
 environment, you might want to configure the operating system so that the
 process that is receiving requests from external sources is the one that
 gets killed by the OOM killer.  With modern Linux you can tell the
 operating system "These processes here are the ones that talk to
 foreigners, so if we run out of RAM and have to kill something, kill one
 of these.".

 That's not nearly as fine-grained as the foolscap approach (for example
 this lets any one of the remote clients of that process make the whole
 process stop working for all of the other remote clients), but it is the
 sort of kludge that people might make do with if the foolscap anti-DoS
 feature turns out to be more trouble than it is worth.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/690#comment:10>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid