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. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
