Managing NFS and NIS, 2nd Edition - Mike Eisler [140]
int ruserok(const char *rhost, int suser, const char *ruser,
const char *luser);
The rhost parameter is the name of the remote host from where the remote user is. The ruser parameter is the login name of the remote user. The luser parameter is the name of local login name that the remote user wants transparent access to. Often luser and ruser are the same, but not always. The suser parameter is set to 1 if the UID of luser is 0, i.e., superuser. Otherwise, suser is set to 0.
ruserok( ) checks first if luser exists; i.e., does getpwnam( ) return success for luser ? It then determines if the remote user and hostname given are trusted on the local host; it is usually called by the remote daemon for these utilities during its startup. If the user or host are not trusted, then the user must supply a password to log in or get "Permission denied" errors when attempting to use rsh. If the remote host trusts the user and host, execution (or login) proceeds without any other verification of the user's identity.
The hosts.equiv file contains either hostnames or host-user pairs:
hostname [username]
If a username follows the hostname, only that combination of user and hostnames is trusted. Netgroup names, in the form +@group, may be substituted for either hostnames or usernames. As with the password file, using a plus sign (+) for an entry includes the appropriate NIS map: in the first column, the hosts map is included, and in the second column, the password map is included. Entries that grant permission contain the hostname, a host and username, or a netgroup inclusion.
The following is /etc/hosts.equiv on host mahimahi:
wahoo
bitatron +
corvette johnc
+@source-hosts
+@sysadm-hosts +@sysadm-users
The first example trusts all users on host wahoo. Users on wahoo can rlogin to mahimahi without a password, but only if the ruser and luser strings are equal.The second example is similar to the first, except that any remote user from bitatron can claim to be any local user and get access as the local user; i.e., luser and ruser do not have to be equal. This is certainly useful to the users who have access to bitatron, but it is very relaxed (or lax) security on mahimahi. The third example is the most restrictive. Only user johnc is trusted on host corvette, and of course luser and ruser (both "johnc") must be the same. Other users on host corvette are not trusted and must supply a password when logging in to mahimahi.
The last two entries use netgroups to define lists of hosts and users. The +@source-hosts entry trusts all hosts whose names appear in the source-hosts netgroup. If usernames are given as part of the netgroup triples, they are ignored. This means that hostname wildcards grant overly generous permissions. If the source-hosts netgroup contained (,stern,), then using this netgroup in the first column of hosts.equiv effectively opens up the machine to all hosts on the network. If you need to restrict logins to specific users from specific machines, you must use either explicit names or netgroups in both the first and second column of hosts.equiv.
The last example does exactly this. Instead of trusting one host-username combination, it trusts all combinations of hostnames in sysadm-hosts and the usernames in sysadm-users. Note that the usernames in the sysadm-hosts netgroup and the hostnames in the sysadm-users netgroup are completely ignored.
Permission may be revoked by preceding the host or user specification with a minus sign (-):
-wahoo
+ -@dangerous-users
The first entry denies permission to all users on host wahoo. The second example negates all users in the netgroup dangerous-users regardless of what machine they originate from (the plus sign (+) makes the remote machine irrelevant in this entry).
If you want to deny permission to everything in both the hosts and password NIS maps, leave hosts.equiv empty.
The .rhosts file uses the same syntax