Bug in remote command login-verification

[Terry Laskodi]

     There's a (mis)feature in the way rlogin and rsh does login verification.
According to the documentation (what little there is; mainly the man page for
rshd in Section 8) but reading the code that actually does the verification,
it is possible to put in the /etc/hosts.equiv file specific users for a specfic
host to do the auto-login, i.e.

	foo bar

says that login bar on machine foo can do remote commands on the servicing
machine, but other user on machine foo are NOT auto-logged in(and had better
have a .rhosts file!!) Well, this is all fine and good, but the way the veri-
fication is done, if a user is specified in the /etc/hosts.equiv file, the
"-l username" to rlogin (and rsh and rexecd, ....) has NO EFFECT on the veri-
fication of remote logins on the servicing machine!!! Granted, one usually
only puts machine names in /etc/hosts.equiv, but we have a network of 4.2
workstations connected to a VAX, and instead of having to tell every user about
the .rhosts file, we would put their machine name and login name in the
/etc/hosts.equiv file. Below is a diff of the relevant piece of code in rlogin
that needs to be changed; one also MUST make the same change in ruserok() in
the C library for rshd, rexecd, etc.



	hostf = pwd->pw_uid ? fopen("/etc/hosts.equiv", "r") : 0;
again:
	if (hostf) {
		char ahost[32];

		while (fgets(ahost, sizeof (ahost), hostf)) {
			char *user;

			if ((user = index(ahost, '\n')) != 0)
				*user++ = '\0';
			if ((user = index(ahost, ' ')) != 0)
				*user++ = '\0';
			if (!strcmp(host, ahost) &&
!/* new line, add */	    (first == 0 || !strcmp(rusername, lusername)) &&
			    !strcmp(rusername, user ? user : lusername)) {
				fclose(hostf);
				return (1);
			}
		}
		fclose(hostf);
	}
	if (first == 1) {
		char *rhosts = ".rhosts";
		struct stat sbuf;

     Unfortunately, this has the side effect of having to require the login
name on the remote machine be the same as the login name on the local machine,
but I can't see any way around that restriction. This usually isn't a problem
because login names are usually unique on cooperating systems, anyway.


				Terry Laskodi
				     of
				Tektronix