On 12/13/2010 2:52 PM, Derrick Brashear wrote: > On March 4, 2003, a delta which is git commit > 30f3ae458cb8ad84ceb1a8e2c6acc45af535d08e (a.k.a. > new-giveup-all-callbacks-rpc-20030303) introduced > RXAFS_GiveUpAllCallBacks.
Some additional important facts: 1. Arla clients implemented this RPC around the time it was added to the OpenAFS tree (1.3.50). 2. OpenAFS Windows client added support for it in the 1.5.21 release. 3. A security advisory was published on 20-Dec-2007 http://www.openafs.org/pages/security/OPENAFS-SA-2007-003.txt The affected servers are versions: OpenAFS 1.3.50 - 1.4.5, OpenAFS 1.5.0 - 1.5.27 4. The Windows client disabled the support for GiveUpAllCallbacks by default (there is a registry option to activate it) in the 1.5.28 release. In the release notes it was indicated that the code would be re-activated in a few months. (This was never done but I would like to.) There is no question that there is a significant benefit from the use of this callback. During a network shutdown, system suspend, or shutdown a client cache manager may only have a few fractions of a second to notify the server that it is no longer going to be reachable. A failure to inform the file server will force the file server to block change requests for resources on which there is an outstanding callback until the client is determined to be unreachable. The question on the table is whether or not it is permissible for acceptable for OpenAFS to begin re-using this functionality three years after the fix was released and the Security Advisory was published. The risk in doing so is that vulnerable file servers (those that have not been upgraded) may crash in a manner similar to that reported in OpenAFS RT-74708. http://rt.central.org/rt/index.html?q=74708 Of course, all of those systems can be upgraded to the current version to fix not only this issue but many others. An alternative approach would involve discarding the existing GiveUpAllCallBacks RPC and allocate a new one. While this mechanism is certainly safe, it does in my opinion create a bad precedent. Anytime an RPC is mis-implemented by any implementation of the AFS3 protocol in a manner that could result in a denial of service the protocol must be altered to prevent its use. Since the release of 1.4.7 which fixed this bug there have been subsequent fixes for file server deadlocks, race conditions that result in crashes, ubik errors that can result in database truncation, extensive rx memory leaks, and more. Although these other issues did not result in a security advisory being published in some ways they are more serious. My personal opinion is that sufficient time has passed to give sites the opportunity to upgrade their servers. Those sites that have not upgraded can easily do so if they begin to experience problems in the future. Continued avoidance of the GiveUpAllCallBacks RPC harms the community members that have deployed the latest clients and servers and does nothing to close the security hole in the affected server instances that are deployed. I am in favor of accepting the proposed patchset and in reactivating this functionality by default in the Windows client with a subsequent patchset. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
