• Choose a category
• All
• Classic-Fiction

By Root 427 0

as the hosts.equiv file, but it is parsed after hosts.equiv. The sole exception to this rule is when granting remote permission to root. When the superuser attempts to access a remote host, the hosts.equiv file is ignored and only the /.rhosts file is read. For all other users, the ruserok( ) routine first reads hosts.equiv. If it finds a positive match, then transparent access is granted. If it finds a negative match, and there is no .rhosts file for luser, then transparent access is denied. Otherwise, the luser 's .rhosts file is parsed until a match, either positive or negative, is found. If an entry in either file denies permission to a remote user, the file parsing stops at that point, even if an entry further down in the file grants permission to that user and host combination.

Usernames that are not the same on all systems are handled through the user's .rhosts file. If you are user julie on your desktop machine vacation, but have username juliec on host starter, you can still get to that remote host transparently by adding a line to your .rhosts file on starter. Assuming a standard home directory scheme, your .rhosts file would be /home/juliec/.rhosts and should contain the name of the machine you are logging in from and your username on the originating machine:

vacation julie

From vacation, you can execute commands on starter using:

% rsh starter -l juliec "ls -l"

or:

% rlogin starter -l juliec

On starter, the ruserok( ) routine looks for a .rhosts file for user juliec, your username on that system. If no entry in hosts.equiv grants you permission (probably the case because you have a different username on that system), then your .rhosts file entry maps your local username into its remote equivalent. You can also use netgroups in .rhosts files, with the same warnings that apply to using them in /etc/hosts.equiv.

As a network manager, watch for overly permissive .rhosts files. Users may accidentally grant password-free access to any user on the network, or map a foreign username to their own Unix username. If you have many password files with private, non-NIS managed entries, watch the use of .rhosts files. Merging password files to eliminate non-uniform usernames may be easier than maintaining a constant lookout for unrestricted access granted through a .rhosts file.

Using netgroups

Netgroups have been used in several examples already to show how triples of host, user, and domain names are used in granting access across the network. The best use of netgroups is for the definition of splinter groups of a large NIS domain, where creating a separate NIS domain would not justify the administrative effort required to keep the two domains synchronized.

Because of the variety of ways in which netgroups are applied, their use and administration are sometimes counterintuitive. Perhaps the most common mistake is defining a netgroup with host or usernames not present in the NIS maps or local host and password files. Consider a netgroup that includes a hostname in another NIS domain:

remote-hosts (poi,-,-), (muban,-,-)

When a user attempts to rlogin from host poi, the local server-side daemon attempts to find the hostname corresponding to the IP address of the originating host. If poi cannot be found in the NIS hosts.byaddr map, then an IP address, instead of a hostname, is passed to ruserok( ). The verification process fails to match the hostname, even though it appears in the netgroup. Any time information is shared between NIS domains, the appropriate entries must appear in both NIS maps for the netgroup construction to function as expected.

Even though netgroups are specified as host and user pairs, no utility uses both names together. There is no difference between the following two netgroups:

group-a (los, mikel,) (bitatron, stern, )

group-b (los, -,) (bitatron, -,) (-, mikel, ) (-, stern, )

Things that need hostnames — the first column of hosts.equiv or NFS export lists — produce the set of hosts {los, bitatron} from both netgroups. Similarly, anything that takes a username, such as the password