I agree with Ken that there may only be a handfull of special cases. There may also be an approach 4.
4. Map compound K5 principal names, to name1/name2 rather then name1.name2 in the PTS. i.e. use K5 separator and rules rather then K4. This would require a site to go through there PTS and look at current entries. But it would be much more in line with K5. The mapping of "host" to "rcmd" and other K4 mapping should also be looked at. If AFS is dropping K4, then it should drop its conventions in the PTS too. Ken Hornstein wrote:
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
-- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
