[OpenAFS] GiveUpAllCallBacks callers

[Simon Wilkinson]

On 14 Dec 2010, at 20:12, Jeffrey Altman wrote:
> 2. There are client versions in the wild that already make
>   this call.

There are two sets of clients which can trigger this bug in the wild:

1) Windows - windows clients between 1.5.21 and 1.5.28, approximately a =
4 month window.

2) Arla - Arla added support for GiveUpAllCallbacks in 2003, and it =
first appeared in Arla 0.36, released in 2004. However, that support =
appers to be only used when making use of Arla's disconnected mode. I =
suspect this means that very few fileservers will see this RPC from this =
source.

On the other hand, making it the default in the Unix client will =
dramatically increase the frequency with which vulnerable fileservers =
see the RPC.

Let's be clear here - if you are running a vulnerable file server and a =
"new" client anywhere on the internet happens to access a read only =
volume on your fileserver, and is then shutdown, that client will =
potentially crash your fileserver.

> 3. There are other bugs in the vulnerable versions that
>   were fixed post 1.4.5 which can:

We're not proposing making a change to the client which causes it to =
start triggering these bugs - I think this is just a distraction. We =
know that people should upgrade - we don't make stable releases for the =
good of our health. But the fact is that for various reasons, people =
don't upgrade their servers nearly as often as they should.

I think that, as responsible developers and vendors, we should not be =
knowingly shipping new code which can crash previous stable releases. =
However, I also find myself agreeing with the various objections that =
have been raised to creating new capability bits, tying together =
unrelated RPCs, and replacing RPCs because of implementation faults.

At this point, I think we should take a look at how other protocols deal =
with the problem of avoiding triggering bugs in badly written peers. The =
use of version string matching is pretty common in this area - witness =
OpenSSH's use of the protocol version information to avoid their client =
from crashing other's servers, Apache's use of header matching to avoid =
breaking non-confornmant HTTP clients, and so on.

If we are going to have a richer AFS ecosystem, then we're going to have =
to gain the ability to deal with these problems. I think that this means =
that in the future, we're going to have to produce a new versioning RPC =
which allows the distribution of structured vendor and version =
information. However, we don't have that RPC now, and it doesn't help us =
with already deployed servers. In the short term, I think it would be =
appropriate to use the RX version identifier.

Whilst using the RX version for application versioning is a layering =
violation, in practice our use of static linkage on Unix means that the =
RX version is almost certainly going to match the application version.

Simon.