> Having the default mapping behavior for existing names change as a result > of a software upgrade to 1.4 would violate the principal of least surprise. > A subtle change like allowing multiple principal names to map to the same > username where previously they did not would be particularly bad, since > such a change has security implications that might not be noticed for some > time. > > I would have no problem if, as a result of the upcoming naming overhaul, we > started mapping V5 principals to usernames containing slashes. I would > have no problem with allowing principals with "." in the first component to > be mapped as a result of an explicit mapping or of a configured > name-mapping pattern (both features I hope to see). And I would have no > problem with a configuration option or even compile-time option which > enabled mapping these names by default. > > However, it is unacceptable for a software upgrade with no configuration > change to result in users unexpectedly gaining privileges or access rights > which they did not previously have. > > > > > Finally, I'm getting a little tired of hearing "well, let's just do XXX > right before 1.4". We are very close to a 1.4 release. This late in the > release cycle, it is appropriate to fix bugs but not to add features or > make behavioral changes. This is particularly important for this version, > which will be the first "stable" version to include support for several > significant platforms. At this point, new features, behavior changes, and > "improvements" should wait for the next development cycle.
Okay, I'll shut up now. But I'd like to be able to run an AFS cell with absolutely no krb4 tickets used anywhere. I don't want to be surprised in 2 months by a brute-force AFS key cracker because the default is to leave krb4 enabled. I can deal with the legacy mapping behavior for now. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
