I didn't follow-up to the list earlier 'cos I hoped that people would take it as fairly obvious that I also don't think that should delay release of the 2.4.20-35.x.legacy update kernels (and I even said so in the bugzilla for 1804). None of the "obvious" tests I carried out with the existing nfs server code allowed me to chgrp a file I didn't own, so I'm not exactly sure under what circumstances the is actually exploitable anyway (maybe it needs root-squash turning off or something, in which case it would only affect hosts you nfs export (rw) to which are untrustworthy). Does anyone actually know the circumstances which can trigger a problem? [ I now have built (one) RH9 kernel with the fchown fix and am running it on a test box... ] Maybe now would be a good time to start thinking about moving (in a few months maybe) to a kernel tree based on 2.4.26/27pre just to reduce the total number of overlapping patches. Now that 2.4 is firmly in "maintenance mode" there won't be any new features added so it should be possible to remove a great number of the existing patches just by using a more modern starting point. e.g. the number of patches in fc1 (based on 2.4.22) is ~106 while we have ~182 in 2.4.20-35.x.legacy Of course without understanding what _all_ of the patches are doing it is always a bit risky to decide which would still need to stay or be changed to be relevant against 2.4.26/27... Currently RedHat (etc) are maintaining kernels based on: RHEL 2.1 2.4.9 RHEL 3 2.4.21 Fedora are maintaining 2.4.22 for fc1 and we have 2.4.20 for RH73/80/9 etc. Wouldn't it make sense to produce a srpm which would be usable for all these systems once fc1 stops being maintained by Fedora? [ I know this will be a lot of work of course! ] -- Jon -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
