CVCONNECT(1M)CVCONNECT(1M)NAMEcvconnect - The WorkShop Debugger Connection Helper
SYNOPSIS
/usr/lib/WorkShop/cvconnect -h host -n pcsnum -p port
DESCRIPTIONcvconnect is invoked by the WorkShop Debugger and Performance tools in
order to establish a secure connection to the debug server, cvpcs. It is
not normally run by users.
SECURITY
The WorkShop tools provide access which is a subset of that provided by
rsh(1). Users may debug or run performance experiments on processes on
their own host, or on any other host in the connected network, subject to
certain constraints. In all cases, the access rights granted to the
session are those of the user ID of the person who begins the session, as
granted to that UID by the system where the target process actually runs.
When the host where the command is typed (the "user" host) is the same as
the host where the target program actually runs (the "target" host),
access is always granted.
When the user host is not the same as the target host ("remote"
debugging), an authentication procedure is conducted before allowing the
session to begin. At the user's end, this procedure is managed by
cvconnect, which is a set-UID program in order to ensure the security of
this negotiation.
Access
The rights granted are always those of the user, as determined by the
numeric user ID. For a remote debugging session, these rights are
granted according to the following authentication protocol:
1) cvconnect initiates a connection to the WorkShop Debugger daemon,
cvpcsd.
2) The daemon checks cvconnect's source port. If the port is not in
the range 512-1023, the daemon aborts the connection.
3) The server checks the client's source address and requests the
corresponding host name (see gethostbyaddr(3N), hosts(4), and
named(1M)). If the hostname cannot be determined, the connection is
aborted.
4) The daemon confirms that the numeric UID in use by cvconnect is
defined on the daemon's system, using getpwuid(3).
5) The daemon then tries to validate the user using ruserok(3N), which
uses the file /etc/hosts.equiv and the .rhosts file found in the
user's home directory. If the user is not the super-user, (user id
0), the file /etc/hosts.equiv is consulted for a list of hosts
Page 1
CVCONNECT(1M)CVCONNECT(1M)
considered ``equivalent''. If the client's host name is present in
this file, the authentication is considered successful. If the
lookup fails, or the user is the super-user, then the file .rhosts
in the home directory of the remote user is checked for the machine
name and identity of the user on the client's machine. If this
lookup fails, the connection is terminated. The -l option prevents
ruserok(3N) from doing any validation based on the user's
``.rhosts'' file, unless the user is the superuser.
6) If necessary, the daemon creates a call socket, forks, sets its UID
and groups to those of cvconnect and execs cvpcs (passing along -l
and -L flags, if any), and records the port ID of the call socket.
If the incoming request is from the same host, user, and debugging
session as an already-running cvpcs, the daemon merely looks up this
call socket port number. Either way, the call socket port ID is
then returned to cvconnect.
7) Cvconnect then calls up cvpcs using the call socket ID returned to
it from cpvcsd. The same authentication steps are performed again,
with the additional requirement that the UID of cvconnect must match
the UID cvpcs inherited from cvpcsd.
8) If the authentication passes, cvpcs acknowledges the connection.
Cvconnect sends it the port ID originally provided it in its
options, on which the true client has been awaiting a call. Cvpcs
connects to the true client, and debugging proceeds.
SEE ALSOcvd(1), cvperf(1), cvpcsd(1m), cvpcs(1m) gethostbyaddr (3N), hosts (4),
named (1M)
Page 2
