On Fri, Jun 15, 2007 at 02:36:11PM -0400, Ken Raeburn wrote: > On Jun 14, 2007, at 11:00, Kyle Wheeler wrote: > > > >Maybe I'm misunderstanding here, but so what? This sounds like the > >equivalent of this: > > > > My program respects the $ALLOW_ROOT_COMPROMISE environment > > variable. You may think root compromises are bad, and that the > > environment variable is ludicrous, and I agree (that "feature" > >was > > added before I took over), but if I removed it then that would be > > an incompatible break from previous versions. > > Don't forget, "... and we have a trivial way to turn it off, though > some programs can't be bothered to use it". Honestly, when one's security software has an "API" consisting of hundreds of functions (many duplicative) and a long history of not including many functions used by the maintainers' own application code in that API documentation, the suggestion "we have another function very much like that in the API, except that it works right" is... well, I personally don't consider it a terribly helpful suggestion. As I'm sure Ken recalls, until around the year 2000 it wasn't actually possible to write a function equivalent to krb5_verify_user() without using functions present in MIT libkrb5, but not documented in the API documentation! (Or, if it was, then none of MIT's own example application code did it that way) Bad library API design like this almost inevitably leads to security holes in application code. What Heimdal has done in this instance seems to me to be a much, much better way out of this particular Kerberos API pit. There are other ways to pass ancillary data to Kerberized applications that must run as root than by insanely dangerous use of environment variables. Thor
