[1877] in Kerberos-V5-bugs
Re:option name from program name needs to go away
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Apr 16 12:03:50 1996
To: Barry Jaspan <bjaspan@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, Doug Engert <DEEngert@anl.gov>,
"Theodore
Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 16 Apr 1996 12:03:17 -0400
In-Reply-To: Barry Jaspan's message of Tue, 16 Apr 96 10:48:16 EDT
>>>>> "Barry" == Barry Jaspan <bjaspan@MIT.EDU> writes:
Doug> The name of the krlogind was also changed, as well as its
Doug> options.I can see changing krlogin to rlogin but why
Doug> krlogind to klogind???
Barry> The reasonthe r was removed from the name has to do with
Barry> what klogind does if you don't give it any options. It
Barry> takes the letters before logind in the name, and treats
Barry> them as options.
Barry> Having krlogind base its behavior on "options" specified in
Barry> the name before "logind" is a total mistake. There is not
Barry> one single good reason for it, and there is an extremely
Barry> good reason not to do it: it is *VERY* confusing, totally
Barry> unlike any other Unix daemon in the world, and dangerous
Barry> because it will inevitably result in misconfigured
Barry> krloginds that allow connections they shoulnd't. The very
Barry> message that started this thread is an excellent example of
Barry> how confusing it can be.
See below .
Barry> It is confusing even before you
Barry> ask the next logical question: how to options specified in
Barry> the name and options specified on the command line
Barry> interact? There is no good answer to that question that is
Barry> understandable and rememberable to normal people.
The answer MIT chose in Beta5 was to ignore options in the
name if options were given on the command line.
The only reason, however, that this code was left in the
release is that your objection was raised after I rewrote the option
parsing code and nothing had (until today) caused me to revisit the
code. It was scheduled for removal as soon as someone got to it.
The new name for klogind and kshd will stand both because
people may be familiar with the old option parsing and because I think
the new names better describe the function of the program.
>>>>> "Doug" == Doug Engert <DEEngert@anl.gov> writes:
Doug> I agree with Barry, having the krlogind look for options on
Doug> is command name is just going to get you in trouble. Now is
Doug> the time to remove that code.
Doug> Doug
Agreed and removed.
Barry> Barry
Doug> Barry Jaspan writes:
>>
Doug> The name of the krlogind was also changed, as well as its
Doug> options.I can see changing krlogin to rlogin but why
Doug> krlogind to klogind???
>> The reasonthe r was removed from the name has to do with what
>> klogind does if you don't give it any options. It takes the
>> letters before logind in the name, and treats them as options.
>>
>> NO NO NO NO NO! WRONG! BAD DOG! BAD DOG!
>>
>> I know I've expressed this opinion before, but I am right, and
>> I am not going to shut up about it.
>>
>> Having krlogind base its behavior on "options" specified in the
>> name before "logind" is a total mistake. There is not one
>> single good reason for it, and there is an extremely good
>> reason not to do it: it is *VERY* confusing, totally unlike any
>> other Unix daemon in the world, and dangerous because it will
>> inevitably result in misconfigured krloginds that allow
>> connections they shoulnd't. The very message that started this
>> thread is an excellent example of how confusing it can be. It
>> is confusing even before you ask the next logical question: how
>> to options specified in the name and options specified on the
>> command line interact? There is no good answer to that
>> question that is understandable and rememberable to normal
>> people.
>>
>> I think I understand the appeal of this design to hackers. It
>> seems clever, fun, and a neat generalization on the idea that
>> "krlogind" and "ekrlogind" differ in their encryption behavior.
>> However, it is totally non-sensical to people that are not
>> hackers and, Guess What!, most people that would like to use
>> Kerberos are not.
>>
>> Command line options are the traditional means of passing
>> arguments to programs. inetd supports passing arguments on any
>> platform worth considering (and if it doesn't, someone using
>> that platform can write a one-line shell script to re-implement
>> this behavior in a way that will make sense to them).
>>
>> I *GUARANTEE* that if you leave this functionality in, it will
>> eventually be a security hole in at least one important site
>> and an embarassment for Kerberos and the MIT development team.
>>
>> Barry
>>
>>
