>Clearly there is a need for many organizations to disable this >functionality. Looking back through the archives of the openafs-info >and openafs-devel mailing lists the topic has been raised approximately >once per year. During that time I have been the primary defender of >this code. However, I am now convinced that although the security >issues are real, the usability issues are more important. > >The question therefore is which of the following should be done: > > 1. leave the code as it is and sites that wish to remove it can do so > by applying the patch locally > 2. remove the code and sites that wish to add the check can do so by > applying the patch locally > 3. conditionally execute the check by adding code to push command > line configuration down into the rxkad security class AND one of: > 1. make the default be off > 2. make the default be on > >At this point I am tempted to say 2 but would be willing to accept >either of 3 provided that someone submitted an acceptable patch.
So I've been one of the more vocal criticizers of this code (mostly because this bit a group here very hard when the switch was made from V4 to V5 tickets). I understand the reasoning behind it, but I think it was too broad of a check to be put into place. I think either 2 or 3 (I'd even be happy with 3.2) is a reasonable approach. But it occurs to me that maybe there is a compromise solution. Perhaps certain instances are the issue? Blocking Kerberos V5 names that end in ".admin" is perhaps a good first-order effort. I admit we can't probably come up with an exhaustive list that covers every situation ... but it would at least take care of the most common example. --Ken _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
