[OpenAFS] GiveUpAllCallBacks callers
Mon, 13 Dec 2010 15:51:21 -0500
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
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
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
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
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
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
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
-----END PGP SIGNATURE-----