Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!madler
From: madler@nntp-server.caltech.edu (Mark Adler)
Newsgroups: comp.sys.next
Subject: Re: Kermit Problem
Message-ID: <1991May27.003509.2763@nntp-server.caltech.edu>
Date: 27 May 91 00:35:09 GMT
References: <15140@ccncsu.ColoState.EDU> <HARDY.91May25224322@golem.ps.uci.edu>
Organization: California Institute of Technology, Pasadena
Lines: 33


Hardy Mayer suggests to the fellow having /dev/cu* access problems:

>> Either chmod +w /dev/cua or chown uucp /usr/local/bin/kermit (or
>> wherever you put kermit , e.g., /LocalApps/kermit).

Well, not exactly.  The first suggestion will work, but it is the
decidedly unkosher way to do it.  The second way won't work, since
it is incomplete.  It is however half of the kosher solution.  You
need to:

    chown uucp kermit
    chmod u+s kermit

as root.  The first command makes uucp the owner of the kermit
executable.  The second command gives kermit the permissions of
it's owner (uucp) when it runs.  This then allows kermit to use
the /dev/cu* devices, since they are also owned by uucp, and
their permissions are crw------- (only the owner and root can
read or write to them).

The reason its done this way is to restrict access to the /dev/cu*
ports to those programs that deal with UUCP lock files properly,
such as kermit, tip, cu, and uucp.  This makes sure that only one
program can think it owns the serial port.

Don't worry about security problems, since kermit knows how to handle
being run setuid, and files are read or written using the permissions
of the person running kermit--not the permissions of uucp.  (This is
true of 5A or later versions of C-Kermit--the fellow has 5A(170).)

Mark Adler
madler@tybalt.caltech.edu