Thus, a well-crafted installation procedure should present the options
and allow the installer to choose the method, if any, for regulating
- access to the dialout devices:
+ accesss to the dialout devices:
a. Check the permissions of the lockfile directory and the dialout
- devices. If they do not allow group or world R/W access, then:
+ devices. If they do not allow group or world R/W accesss, then:
b. "Your UUCP lockfile directory and/or dialout devices require
- privilege to access. You must either change their permissions or
+ privilege to accesss. You must either change their permissions or
install Kermit with privileges."
c. "If you wish to install Kermit with privileges, it will be given
the same owner, group, and permissions as the cu program so it can
Hundreds of prebuilt C-Kermit binaries are available on the CDROM in
the BINARY tree [NOTE: The C-Kermit CDROM is still for version 7.0],
and at our ftp site in the [72]kermit/bin area (with names starting
- with "ck"), also accessible on the [73]C-Kermit website. To install a
+ with "ck"), also accesssible on the [73]C-Kermit website. To install a
prebuilt binary:
a. Rename the binary to "wermit".
* Many and varied security libraries for building a secure version
(Kerberos, SSL/TLS, SRP, Zlib,...) These are required only if you
select a secure target.
- * For the curses-based fullscreen file-ransfer display, the curses or
- ncurses header file(s) and library, and probably also the termcap
- and/or termlib library. Note that the names and locations of these
- files and libraries are likely to change capriciously with every
- new release of your Unix product. If you discover that the C-Kermit
- build procedure fails because your curses and/or termxxx headers or
- libraries are not named or located as expected, please [91]let us
- know. In the meantime, work around by installing symlinks.
+ * For the curses-based fullscreen file-transfer display, the curses
+ or ncurses header file(s) and library, and probably also the
+ termcap and/or termlib library. Note that the names and locations
+ of these files and libraries are likely to change capriciously with
+ every new release of your Unix product. If you discover that the
+ C-Kermit build procedure fails because your curses and/or termxxx
+ headers or libraries are not named or located as expected, please
+ [91]let us know. In the meantime, work around by installing
+ symlinks.
* IMPORTANT: Modern Linux distributions might give you the choice
during installation of whether to install the "ncurses development
package" (perhaps called "ncurses-devel"). If you did not install
(Also see the [110]Configurations Options document, [111]Section 8).
Lots of new features have been added in versions 7.0 and 8.0 that
- require access to new symbols, APIs, libraries, etc, and this will no
+ require accesss to new symbols, APIs, libraries, etc, and this will no
doubt cause problems in compiling, linking, or execution on platforms
where 6.0 and earlier built without incident. This section contains
what we know as of the date of this file.
available.
In most cases, you need to be root to install C-Kermit, if only to gain
- write access to directories in which the binary and manual page are to
+ write accesss to directories in which the binary and manual page are to
be copied. The C-Kermit binary should be installed in a directory that
is in the users' PATH, but that is not likely to be overwritten when
you install a new version of the operating system. A good candidate
make install
IMPORTANT: IF C-KERMIT IS TO BE USED FOR DIALING OUT, you must also do
- something to give it access to the dialout devices and lockfile
+ something to give it accesss to the dialout devices and lockfile
directories. The 'install' target does not attempt to set Kermit's
owner, group, and permissions to allow dialing out. This requires
privileges, open eyes, and human decision-making. Please read
routines in [217]ckutio.c and see if you can figure out what's
wrong. If you can't, rebuild with -DNOJC.
o. Give a SET LINE command for a dialout device, e.g. "set line
- /dev/tty00". If you got some kind of permission or access denied
+ /dev/tty00". If you got some kind of permission or accesss denied
message, go read [218]Section 10 and then come back here.
p. After giving a successful SET LINE command, type "show comm" to see
the communication parameters. Do they make sense?
normal, etc, but then after returning from a CONNECT session, the
prompt no longer appears, try rebuilding with -DCKCONINTB4CB.
ae. (8.0.206 or later) Type some commands at the C-Kermit prompt. Can
- you use the Up-arrow and Down-arrow keys on your keyboard to access
- Kermit's command history? If not, and you're a programmer, take a
- look at the USE_ARROWKEYS sections of ckucmd.c.
+ you use the Up-arrow and Down-arrow keys on your keyboard to
+ accesss Kermit's command history? If not, and you're a programmer,
+ take a look at the USE_ARROWKEYS sections of ckucmd.c.
8. REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE
internally.
On the downside, ANSI C compilation increases the
- administrative/bureacratic burden, spewing out countless unneeded
+ administrative/bureaucratic burden, spewing out countless unneeded
warnings about mismatched types, especially when we are dealing with
signed and unsigned characters, requiring casts everywhere to shut up
the mindless complaints -- there is no use for signed chars in Kermit
None of these standards simplifies life for portable applications like
C-Kermit -- each one is simply one more environment to support (or
circumvent, as in many cases these standards do more harm than good by
- denying access to facilities we need, e.g. as noted in above in
+ denying accesss to facilities we need, e.g. as noted in above in
[271]9.1.1).
9.2. Library Issues
Since Red Hat 7.2, about 2002, Linux does not leave the lockfile
handling to each application, but instead provides an external
application, /usr/sbin/lockdev, that all applications should invoke
- when they need to access a serial port; lockdev locks and unlocks
+ when they need to accesss a serial port; lockdev locks and unlocks
the port without requiring the application to have privileges, since
the privileges on the lockfile directory are assigned to lockdev.
C-Kermit 8.0.211 and later support this method. But C-Kermit still
needs to be able to open the port itself, and therefore if the
- port's permissions do not allow read/write access to the general
+ port's permissions do not allow read/write accesss to the general
public, the general rule must still be followed: in the most common
case, it must be SETGID to the group uucp (explained below). If a
pre-8.0.211 version of C-Kermit is to be installed for use with
Peripheral Devices => Terminals and Modems => Add Modem).
Unlike most other multiuser, multitasking operating systems, Unix
- allows multiple users to access the same serial device at the same
+ allows multiple users to accesss the same serial device at the same
time, even though there is no earthly reason why two users should do
this. When they do, user A will read some of the incoming characters,
and user B will read the others. In all likelihood, neither user will
see them all. Furthermore, User B can hang up User A's call, and so
one.
- Rather than change Unix to enforce exclusive access to serial devices
+ Rather than change Unix to enforce exclusive accesss to serial devices
such as ttys, when it might still have been possible, Unix developers
opted for a "lock file" mechanism. Any process that wants to open a tty
device should first check to see if a file of a certain name exists,
* PIDs recycle. If the lockfile was created by PID 1234, which later
crashed without removing the lockfile, and then a new process 1234
exists a the time the lockfile is checked, the lockfile will be
- improperly taken as valid, and access to the device denied
+ improperly taken as valid, and accesss to the device denied
unnecessarily.
Several techniques address the problem of multiple names for the same
dialout device, like /dev/cua0 or /dev/ttyS0, whose purpose is to hide
the details of the actual driver from the user. So if one user opens
/dev/modem, a lockfile called LCK..modem is created, which does not
- prevent another user from simulataneously opening the same device by
- its real name.
+ prevent another user from simultaneously opening the same device by its
+ real name.
On SCO Unix platforms, we have a slightly different problem: the same
device is, by convention, known by "lowercase" and "uppercase" names,
means that you have SET CARRIER ON xx, where xx is the number of
seconds to wait for carrier, and carrier did not appear within xx
seconds. Solution: SET CARRIER AUTO or OFF.
- b. "Sorry, access to lock denied." Kermit has been configured to use
+ b. "Sorry, accesss to lock denied." Kermit has been configured to use
lockfiles, but (a)the lockfile directory is write-protected against
- you, or (b) it does not exist. The "access to lock denied" message
+ you, or (b) it does not exist. The "accesss to lock denied" message
will tell you the reason. If the directory does not exist, check to
make sure Kermit is using the right name. Just because version n of
- your Unix used a certain lockfile directory is no gurantee that
+ your Unix used a certain lockfile directory is no guarantee that
version n.1 does not use a different one. Workaround: ask the
system administrator to install a symbolic link from the old name
to the new name. Other solutions: (see below)
- c. "Sorry, access to tty device denied." The tty device that you
+ c. "Sorry, accesss to tty device denied." The tty device that you
specified in your SET LINE command is read/write protected against
you. Solution: (see below)
d. "Sorry, device is in use." The tty device you have specified is
telephone calls are not controlled -- anybody on your system can
make them, without having to belong to any particular group, and
this could run up your phone bill.
- b. Use groups to regulate access. Normally the lockfile directory and
+ b. Use groups to regulate accesss. Normally the lockfile directory and
and the dialout devices will have the same group (such as uucp). If
so, then put everybody who's allowed to dial out into that group,
and make sure that the lockfile directory and the tty devices have
su% chmod 660 /dev/ttyXX
User whatever tool is available on your platform to add users to
- the appropropriate group (e.g. edit the /etc/group file).
+ the appropriate group (e.g. edit the /etc/group file).
c. Have the superuser change Kermit to run setuid and/or setgid to the
owner and/or group of the lockfile directory and the tty devices if
necessary), typically uucp (see [331]next section), but NOT root.
su% chown uucp /dev/ttyXX ; chmod 600 /dev/ttyXX
In some cases, the owner and group must be distinct; the key point
- is that read/write access is required to both the UUCP lockfile
+ is that read/write accesss is required to both the UUCP lockfile
directory and the tty itself.
If you make C-Kermit setuid or setgid to root, it refuses to run:
crw-r----- 1 uucp uucp 5, 67 Feb 11 06:23 /dev/cua3
drwxrwxr-x 3 root uucp 1024 Feb 11 06:22 /var/lock
- requires suid uucp to get read/write access on /dev/cua3 and sgid to
- get read/write access on /var/lock (since you can't set Kermit's uid or
- gid to root).
+ requires suid uucp to get read/write accesss on /dev/cua3 and sgid to
+ get read/write accesss on /var/lock (since you can't set Kermit's uid
+ or gid to root).
The reason Kermit can't be setuid or setgid to root has to do with
the fact that some Unix OS's can't switch user or group IDs in that
setgid to root means that Unix C-Kermit can't be used to make rlogin
connections by non-root users. (The rlogin port is privileged, which
is why the regular rlogin command is setuid root -- which is safe
- because the rlogin program never has to create or access files like
+ because the rlogin program never has to create or accesss files like
Kermit does.)
For the lockfile mechanism to achieve its desired purpose -- prevention
- of access to the same tty device by more than one process at a time --
+ of accesss to the same tty device by more than one process at a time --
ALL programs on a given computer that open, read or write, and close
tty devices must use the SAME lockfile conventions. Unfortunately, this
is often not the case. Here is a typical example of how this can go
a. If there may be more than one person running Kermit at the same
time, competing for the same tty device, then create a special
lockfile directory just for Kermit, for example, /usr/spool/kermit,
- and make sure you have read/write access to it. Then add the
+ and make sure you have read/write accesss to it. Then add the
following to your makefile target CFLAGS, as shown earlier:
-DLOCK_DIR=\\\"/usr/spool/kermit\\\"
switch between real and effective uid, add -DSETREUID to your makefile
target.
- WARNING: There are two calls to access() in [337]ckufio.c, by which
+ WARNING: There are two calls to accesss() in [337]ckufio.c, by which
Kermit checks to see if it can create an output file. These calls
will not work correctly when (a)you have installed C-Kermit setuid
or setgid on a BSD-based Unix system, and (b) the
saved-original-effective-uid/gid feature is not present, and (c) the
- access() function always checks what it believes to be the real ID
+ accesss() function always checks what it believes to be the real ID
rather than the effective ID. This is the case, for example, in
Olivetti X/OS and in NeXTSTEP. In such cases, you can force correct
- operation of access() calls by defining the symbol SW_ACC_ID at
+ operation of accesss() calls by defining the symbol SW_ACC_ID at
compile time in CFLAGS.
If you have a version of Unix that does not allow a process to switch
MORAL: Are you thoroughly sickened and/or frightened by all that you
have just read? You should be. What is the real answer? Simple. Serial
devices -- such as ttys and magnetic tapes -- in Unix should be opened
- with exclusive access only, enforced by the Unix kernel. Shared access
- has no conceivable purpose, legitimate or otherwise, except by
+ with exclusive accesss only, enforced by the Unix kernel. Shared
+ accesss has no conceivable purpose, legitimate or otherwise, except by
privileged system programs such as getty. The original design dates
from the late 1960s, when Unix was developed for laboratory use under a
philosophy of trust by people within shouting distance of each other --
emergence of Unix from the laboratory into the commercial market, we
have seen every vestige of openness -- but this one -- stripped away.
I'd like to see some influential Unix maker take the bold step of
- making the simple kernel change required to enforce exclusive access to
- serial devices. (Well, perhaps not so simple when bidirectionality must
- also be a goal -- but then other OS's like VMS solved this problem
+ making the simple kernel change required to enforce exclusive accesss
+ to serial devices. (Well, perhaps not so simple when bidirectionality
+ must also be a goal -- but then other OS's like VMS solved this problem
decades ago.)
12. CONFIGURING UNIX WORKSTATIONS
[ [348]Top ] [ [349]Contents ] [ [350]Next ] [ [351]Previous ]
- If C-Kermit constitently dumps core at the beginning of a file
+ If C-Kermit consistently dumps core at the beginning of a file
transfer, look in SHOW FEATURES for CKREALPATH. If found, rebuild with
-DNOREALPATH and see if that fixes the problem (some UNIXes have
realpath() but it doesn't work).
Subsystem kermit /some/path/kermit-sshsub
(where /some/path is the fully specified directory where the symlink
- is.) This is similar to the line that sets up the SFTP susbsystem.
+ is.) This is similar to the line that sets up the SFTP subsystem.
Example:
Subsystem sftp /usr/local/libexec/sftp-server
projects / ckermit.git / blobdiff