[OpenAFS] GiveUpAllCallBacks callers

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD8363DB0F0D5E46EDBE972A9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=3D74708

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


--------------enigD8363DB0F0D5E46EDBE972A9
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)

iQEcBAEBAgAGBQJNBodLAAoJENxm1CNJffh43CsIAIkjmxLEvN7l1sN7JSMq4bA/
C8DEGJx2LzHgK9G/OWsMgWfC5QUM1HSkS/Wd/nK0rzfNQ4YG5ynlkJfbyBrHfw/x
4X33JPNUN74tCUC936ZBZRadoprt5TjxjaSknZkVG+M4F3oEu0QakeivvZKs+lxR
M1VE3t4URx6wC2+w55+Bu/LaqTLoF3eLuVWbApCSSFVaUP3HmXCuXI5esa9BT7UZ
6O80CzM0Oja8eW9YnPh+NRr1pQFajWW4URu+aQfDqanege5+QuOS6rPbmSqgJSvN
jaF6cWa0/sAjKyU8B6yYmKvxToQagUw/gwlcOU0RFHfapsFI80f+JNvgVnNpA4U=
=Nwin
-----END PGP SIGNATURE-----

--------------enigD8363DB0F0D5E46EDBE972A9--