4.3BSD-Reno/src/usr.bin/uucp/USERFILE.0

USERFILE(5)		      1990		      USERFILE(5)



NNAAMMEE
     USERFILE - UUCP pathname permissions file

DDEESSCCRRIIPPTTIIOONN
     The _U_S_E_R_F_I_L_E file specifies the file system directory trees
     that are accessible to local users and to remote systems via
     UUCP.

     Each line in _U_S_E_R_F_I_L_E is of the form:

     [_l_o_g_i_n_n_a_m_e],,[_s_y_s_t_e_m] [ cc ] _p_a_t_h_n_a_m_e [_p_a_t_h_n_a_m_e] [_p_a_t_h_n_a_m_e]

     The first two items are separated by a comma; any number of
     spaces or tabs may separate the remaining items.  Lines
     beginning with a `#' character are comments.  A trailing `\'
     indicates that the next line is a continuation of the
     current line.

     _L_o_g_i_n_n_a_m_e is a login (from /_e_t_c/_p_a_s_s_w_d) on the local
     machine.

     _S_y_s_t_e_m is the name of a remote machine, the same name used
     in _L._s_y_s(5).

     _c denotes the optional _c_a_l_l_b_a_c_k field.  If a cc appears here,
     a remote machine that calls in will be told that callback is
     requested, and the conversation will be terminated.  The
     local system will then immediately call the remote host
     back.

     _P_a_t_h_n_a_m_e is a pathname prefix that is permissible for this
     _l_o_g_i_n and/or _s_y_s_t_e_m.

     When _u_u_c_i_c_o(8C) runs in master role or _u_u_c_p(1C) or _u_u_x(1C)
     are run by local users, the permitted pathnames are those on
     the first line with a _l_o_g_i_n_n_a_m_e that matches the name of the
     user who executed the command.  If no such line exists, then
     the first line with a null (missing) _l_o_g_i_n_n_a_m_e field is
     used.  (Beware: _u_u_c_i_c_o is often run by the superuser or the
     UUCP administrator through _c_r_o_n(8).)

     When _u_u_c_i_c_o runs in slave role, the permitted pathnames are
     those on the first line with a _s_y_s_t_e_m field that matches the
     hostname of the remote machine.  If no such line exists,
     then the first line with a null (missing) _s_y_s_t_e_m field is
     used.

     _U_u_x_q_t(8) works differently; it knows neither a login name
     nor a hostname.  It accepts the pathnames on the first line
     that has a null _s_y_s_t_e_m field.  (This is the same line that
     is used by _u_u_c_i_c_o when it cannot match the remote machine's
     hostname.)



Printed 7/4/90		      June				1






USERFILE(5)		      1990		      USERFILE(5)



     A line with both _l_o_g_i_n_n_a_m_e and _s_y_s_t_e_m null, for example

	  ,, //vvaarr//ssppooooll//uuuuccppppuubblliicc

     can be used to conveniently specify the paths for both "no
     match" cases if lines earlier in _U_S_E_R_F_I_L_E did not define
     them.  (This differs from older Berkeley and all USG ver-
     sions, where each case must be individually specified.  If
     neither case is defined earlier, a "null" line only defines
     the "unknown login" case.)

     To correctly process _l_o_g_i_n_n_a_m_e on systems that assign
     several logins per UID, the following strategy is used to
     determine the current _l_o_g_i_n_n_a_m_e:

     1)   If the process is attached to a terminal, a login entry
	  exists in /_v_a_r/_r_u_n/_u_t_m_p, and the UID for the _u_t_m_p name
	  matches the current real UID, then _l_o_g_i_n_n_a_m_e is set to
	  the _u_t_m_p name.

     2)   If the UUSSEERR environment variable is defined and the UID
	  for this name matches the current real UID, then _l_o_g_i_n_-
	  _n_a_m_e is set to the name in UUSSEERR.

     3)   If both of the above fail, call _g_e_t_p_w_u_i_d(3) to fetch
	  the first name in /_e_t_c/_p_a_s_s_w_d that matches the real
	  UID.

     4)   If all of the above fail, the utility aborts.

FFIILLEESS
     /usr/lib/uucp/USERFILE
     /usr/lib/uucp/UUAIDS/USERFILE   USERFILE example

SSEEEE AALLSSOO
     uucp(1C), uux(1C), L.cmds(5), L.sys(5), uucico(8C),
     uuxqt(8C)

NNOOTTEESS
     The UUCP utilities (_u_u_c_i_c_o, _u_u_c_p, _u_u_x, and _u_u_x_q_t) always
     have access to the UUCP spool files in /_v_a_r/_s_p_o_o_l/_u_u_c_p,
     regardless of pathnames in _U_S_E_R_F_I_L_E.

     If uuuuccpp is listed in _L._c_m_d_s(5), then a remote system will
     execute _u_u_c_p on the local system with the _U_S_E_R_F_I_L_E
     privileges for its _l_o_g_i_n, not its hostname.

     _U_u_c_i_c_o freely switches between master and slave roles during
     the course of a conversation, regardless of the role it was
     started with.  This affects how _U_S_E_R_F_I_L_E is interpreted.





Printed 7/4/90		      June				2






USERFILE(5)		      1990		      USERFILE(5)



WWAARRNNIINNGG
     _U_S_E_R_F_I_L_E restricts access only on strings that the UUCP
     utilities identify as being pathnames.  If the wrong holes
     are left in other UUCP control files (notably _L._c_m_d_s), it
     can be easy for an intruder to open files anywhere in the
     file system.  Arguments to _u_u_c_p(1C) are safe, since it
     assumes all of its non-option arguments are files.  _U_u_x(1C)
     cannot make such assumptions; hence, it is more dangerous.

BBUUGGSS
     The _U_U_C_P _I_m_p_l_e_m_e_n_t_a_t_i_o_n _D_e_s_c_r_i_p_t_i_o_n explicitly states that
     all remote login names must be listed in _U_S_E_R_F_I_L_E.  This
     requirement is not enforced by Berkeley UUCP, although it is
     by USG UUCP.

     Early versions of 4.2BSD _u_u_x_q_t(8) erroneously check UUCP
     spool files against the _U_S_E_R_F_I_L_E pathname permissions.
     Hence, on these systems it is necessary to specify
     /_v_a_r/_s_p_o_o_l/_u_u_c_p as a valid path on the _U_S_E_R_F_I_L_E line used by
     _u_u_x_q_t.  Otherwise, all _u_u_x(1C) requests are rejected with a
     "PERMISSION DENIED" message.


































Printed 7/4/90		      June				3