[6542] in Kerberos
Re: Request for input: proposed krshd and krlogind option reorganization
daemon@ATHENA.MIT.EDU (Jonathan Kamens)
Sat Jan 27 13:43:41 1996
To: kerberos@MIT.EDU
Date: 27 Jan 1996 18:37:00 GMT
From: jik@annex-1-slip-jik.cam.ov.com (Jonathan Kamens)
I agree with pretty much all of Barry's comments. I have a few additional
comments to make in response to Sam's response to Barry....
In article <tsl7myizido.fsf@tertius.mit.edu>, hartmans@MIT.EDU (Sam Hartman) writes:
|> The rhosts support in krlogind is somewhat different than in
|> the vendor rlogind. However, I think it's *more* broken than the
|> normal krlogind so I probably will punt it at the first sign of
|> difficulty unless someone gives an example of when it is useful.
The .rhosts support in krlogind and krshd JUST DOESN'T WORK, because it relies
on krlogind running on a reserved port, and the klogin and eklogin ports are
*not* reserved.
Now, granted, a site which wanted to support both .rhosts and .k*login could
change the klogin and eklogin services, at their site, to make them reside on
a reserved port. But this is would be really gross. Besides, one of the
whole points of Kerberos authentication is that DNS-based authentication is
insecure. Why should something which purports to be a more secure version of
rlogind/rshd support an insecure authentication method?
In short, I agree with Barry -- punt .rhosts entirely. People who want to
support .rhosts can run the vendor rlogind/rshd and tell people to connect
using UCB rlogin/rsh.
|> Unfortunately, some operating systems (Remember /etc/servers
|> on SunOS 3?) do not allow you to specify command line arguments. The
|> way our code currently works is to ignore the name of the program if
|> any arguments are specified. I.E. in your example, it would be a
|> non-encrypted krb5 logind. (I'm considering dropping the handling of
|> the program name even with this portability problem, but haven't
|> really come to a firm decision yet.)
1) Is there really *anybody* using the MIT Kerberos 5 distribution on a system
which does not allow servers to be run with command-line flags?
2) If there are such people, are they not capable of writing a shell-script
wrapper which execs krlogind or krshd with the correct command-line options?
In short, I agree with Barry that accepting that stuff on the command-line was
always confusing ahd chaotic, and that it doesn't add any useful
functionality. Punt it.
|> Barry> While I'm on the topic of improving krlogin et al, I also
|> Barry> strongly feel that the krlogin, krsh, and krcp clients
|> Barry> SHOULD NOT fall back to UCB versions if the Kerberos
|> Barry> versions fail. The reasons are simple:
|>
|> Barry> (1) It is a security hole.
|>
|> So is using non-encrypted clients. (There is no fallback if
|> encryption is enabled.)
Sam, I don't understand what you mean here.
jik
