iksd.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

Direction
  The letter 'o' if the file was transferred Out, and 'i' if the file was
  transferred In.

User class
  The letter 'r' for real users, or 'a' for anonymous users.

User identification
  The user ID of a real user, or the password given by an anonymous user.

Server identification
  The string "iks" (Internet Kermit Server), or if C-Kermit is running
  in user mode, "kermit".  This distinguishes a Kermit transfer log
  record from a WU-FTPD record, which contains "ftp" in this field.

Authentication class
  The digit '1' if we know the user's ID on the client system, 
  otherwise '0'.  Currently, always '0'.

Authenticated user
  If the authentication class is '1', this is the user's ID on the client
  system.  Otherwise it is an asterisk ('*').  Currently it is always an
  asterisk.

4.4. The IKSD Configuration File

The IKSD configuration file is a place to put commands that should always
be executed for every client, real or anonymous.

When C-Kermit is started as IKSD, it always begins by reading the IKSD
configuration file, if any.  By default this is /etc/iksd.conf (you may
change the definition at compile time by adding -DIKSDCONF=\"filename\" to
CFLAGS).  This file contains ordinary C-Kermit commands.  Normally these
would be SET or DISABLE commands.  In case any commands in this file write to
standard output, remember that IKSD's standard output is the connection to
the client.  For more ideas about what can go in the iksd.conf file,
read the next section -- the difference is that when you put commands in
the iksd.conf file, they apply not only to anonymous users, but to real
users too.  So, for example, if you want to disable uploads for all users,
you could put DISABLE SEND in the iksd.conf file, whereas if you wanted to
disable them only for anonymous users, you would put this command in the
anonymous-user initialization file.

The IKSD configuration file is executed before the user logs in (or is
otherwise authenticated), before the C-Kermit initialization file, and before
any extended-format command line options that start with "--", but after any
that are marked CM_PRE in the table in Section 4.1, or that start with "-+".
Since execution occurs before login, the \v(user) variable is meaningless
here.

4.5. The Initialization File

When a real user logs in to the IKSD, the C-Kermit initialization file is
executed in the normal manner, depending on the compile-time configuration of
the IKSD.  Normally, the user's own .kermrc file is executed, and this, in
turn, executes the user's customization file, .mykermrc.  If the IKSD was
built with the CK_SYSINI or CK_DSYSINI compile-time options (described in
ckccfg.txt), a single, shared system-wide initialization file is executed
instead; this may, in turn, execute a customization file out of the user's
home directory.  You may override C-Kermit's automatic selection of
initialization with the regular C-Kermit -y or -Y options on the IKSD command
line, described in the C-Kermit manual.

For anonymous users, the default initialization file, if any, is .kermrc in
the chroot'd file system.  This default may be overridden with the
--initfile:xxx command-line option.  The system administrator may include
commands in this file to disable selected services for anonymous users, e.g.:

  disable delete  ; Don't let anonymous users delete files
  disable send    ; Don't let anonymous users send files

Of course, any Kermit commands at all may be included: settings, macro
definitions, etc.  (Also see Section 5.5.)

When the sysadmin specifies the initialization file, this allows a high degree
of fine-grained control over who is allowed access to what commands and
resources, using standard C-Kermit commands, functions, and variables.  The
following are particularly useful:

\v(date), \v(ndate)
  The current date, in case you want to restrict access by date.
  (Also read about the new date-related functions in Section 1.6 of
  ckermit2.txt.)

\v(day), \v(nday)
  The day of the week, in case you want to restrict access to certain days
  of the week.

\v(home)
  The user's home directory.

\v(host)
  The hostname of the IKS.

\v(ipaddress)
  The IP address of the IKS.  This and/or \v(host) may be used when you are
  running an IKS on multiple hosts and want to have different setups on each,
  but still have a common initialization file.

\v(line)
  The IP host name or address of the client's host.

\v(time), \v(ntime)
  The current time of day, in case you wish to restrict access to certain
  times of day.

\v(userid)
  The ID with which the user logged in to the IKS.  For anonymous logins,
  this is "ftp".

So, for example, if the sysadmin wishes to prevent user "olga" from using the
IKS on Mondays, the initialization file could contain a command like:

  if equal \v(user) olga -
    if equal \v(nday) 1 -
       exit 1 Sorry Olga - please come back another day

Or suppose it is desirable to block access from all xyzcorp.com hosts between
9:00am and noon:

  if match \v(line) *.xyzcorp.com -
    if lgt \v(time) 09:00:00 -
      if llt \v(time) 12:00:00 -
         exit 1 Sorry - Please come back after noon

Or suppose a certain user is to be allowed to GET files from the server, but
not SEND, PRINT, or MAIL them:

  xif equal \v(user) ivan {
      disable send
      disable print
      disable mail
      disable enable
  }
    
5. Access to Services

The IKSD behaves at runtime just like the regular C-Kermit program, with
any restrictions resulting from compile-time options, and with the differences
noted in this section and in Section 4.

5.1. Automatic Settings

When C-Kermit is started as an Internet Kermit Service, the following settings
occur automatically:

 a. Login (authentication) is required.
 b. Shell access is disabled.
 c. Server-side Telnet negotiation is enabled.
 d. SET RELIABLE ON (see ckermit2.txt).
 e. FAST file-transfer settings, including "cautious" unprefixing.
 f. No flow control, no parity.

Items d-f can be overridden with command-line options and/or in the
initialization file.

5.2. Authentication

The IKSD command prompt will not appear, and no commands may be given, before
the user is authenticated.

When the IKSD has been started without the '-x' command-line option, it issues
a Username: prompt.  The user may type a username at the prompt, in which case
a Password: prompt is issued, and the user must enter a password.  Three login
attempts are allowed, with a pause enforced between each one.  If all three
fail, the connection is closed.

The user may also authenticate from the client by sending a [ REMOTE ] LOGIN
command (again, only 3 tries are allowed), or by Telnet Authentication
negotiations.  Prior to authentication, the IKSD will respond to only the
following client commands:

  [ REMOTE ] LOGIN
  [ REMOTE ] LOGOUT
  REMOTE HELP (or RHELP)
  REMOTE EXIT (or REXIT)
  BYE

Once authenticated, the user may not re-authenticate or change identities.

The connection persists until it is broken in any of the following ways:

 a. Client sends BYE or REMOTE EXIT (REXIT) or [ REMOTE ] LOGOUT to IKSD.
 b. Client sends FINISH to IKSD that has been started with '-x'.
 c. User gives HANGUP or CLOSE command to the client.
 d. User gives EXIT, QUIT, or LOGOUT command at IKSD prompt. 

The connection is also closed if the user exits from the client, but only if
it was an end-to-end Telnet connection.  There can be no guarantee that
exiting from a serial communication program will close and hang up the serial
connection.

5.3. The DISABLE Command

In the IKSD, the DISABLE command applies not only to client/server functions,
but also to the corresponding commands when given at the prompt.  For example,
DISABLE DELETE disables not only REMOTE DELETE commands given from the client,
but also DELETE commands given at the IKSD's command prompt, as well as
implicit forms of file deletion, such as when the target of a COPY command is
an existing file.

The DISABLE ENABLE command is irreversible; once this command is given, the
ENABLE command can not be re-enabled, and therefore no other disabled commands
can be enabled either.  ENABLE is DISABLEd automatically for anonymous users,
so any DISABLE commands in the anonymous-user initialization file (Section 4.4)
are also irreversible.

5.4. Shell Access

All forms of system and shell access are disabled in the IKS.  Thus the user
can not execute REMOTE HOST commands from the client, nor access the shell
from the IKS command prompt via shell escapes (!), the RUN or PUSH command, or
by specifying pipes or filters in file-transfer commands, or by pipe
specifications in REMOTE commands, or in any other way.  This is true even if
the executable was built without the NOPUSH compile-time option.

5.5. Anonymous Users

Anonymous users are allowed by default, but can be denied with --anonymous:no
on the command line (Section 4.1).

Anonymous users are handled in about the same way as they are by ftpd.  Their
effective user ID is set to "ftp" and their file-system access is restricted
to the tree rooted at the home directory of the "ftp" user, normally /pub/ftp,
via chroot.  If /pub/ftp does not exist, login will fail.  In that case (or
for any other desired reason), the anonymous root directory can be changed
with the --root: option, e.g. --root:/tmp.  Note that, unlike ftpd, iksd does
not necessarily require any particular binaries (such as ls) to be in the
chroot'd tree.  DLLs might be another story, but so far these have not been
needed, even with dynamically linked Kermit binaries (at least in Linux and
Solaris).  Should DLLs be a problem, use a statically linked Kermit binary
(if possible), or install the needed DLLs in the anonymous root.

File access is according to user "ftp" and the directory and file permissions
of the /pub/ftp tree.  If anonymous uploads are to be allowed, then usually
only specific directories (often with a name like "incoming") are given write
permission, and any files that are created in such a directory have owner
"ftp", with the group set to the group of the directory.  As noted in section
4.1, the permission for all files created by anonymous users is 0040
(group-read only), or whatever else the sysadmin has specified in the
--permissions: command-line option.

Thus, if you already have a public ftp server, most likely everything is set
up appropriately already.  If anonymous ftp is allowed (by the presence of
a valid user "ftp" in your system's password file), it will be allowed also
for IKSD unless explicitly disallowed on the IKSD command-line (or if
/pub/ftp doesn't exist and you did not supply a --root: option on the command
line).

In addition to the FTP-like restrictions, certain Kermit services are always
denied to anonymous users.  These include:

 . PRINT (at IKSD prompt) and REMOTE PRINT (from client)
 . MAIL (or SEND /MAIL) at IKSD prompt and from client.
 . Creation of any logs (transaction, debug, packet, etc).
 . No file may be deleted, including implicitly, e.g. by the COPY command.
 . FILE COLLISION is set to RENAME and may not be changed.

The latter three provisions mean that anonymous users can not delete,
overwrite, rename, or alter any existing files in any way, whether by file
transfer or with the DELETE or RENAME command.

Note that IKSD, like FTPD, does not allow directory creation by anonymous
users, even when file/directory permissions would otherwise allow it.  To
change this, add:

  enable mkdir    ; Enable directory creation

to /pub/ftp/.kermrc (or whatever other initialization file you have designated
for anonymous users with --initfile).  Similarly for directory removal:

  enable rmdir    ; Enable directory removal

Of course directories can be removed only if (a) they are empty, and (b)
their permissions allow it.

5.6. Management Information

The command-line argument vector, normally accessible in the \&@[] array,
the top-level \%0..9 variables, or by other means, is inaccessible to IKSD
users.  Thus IKSD clients can not discover the IKSD startup path or options,
the logfile pathnames or directories, logging level, etc.

6. Open Issues

Several services that are normally provided by C-Kermit are not available
when it is an Internet Kermit Service Daemon.

6.1. Connection Establishment

If the user has access to the IKSD command prompt, why not allow her to "set
host" or "set line" from there to another place?  Obviously this would be a
security risk if allowed for anonymous users.  For authenticated users, it
should be OK, but is not currently possible for Telnet connections since the
IKSD is already a Telnet server on the incoming connection, and is not
designed to conduct two separate Telnet sessions simultaneously.  It might be
possible to allow the user to make a dialout connection, but some coding and
testing would be needed should this prove desirable.

6.2. Shell Access

Shell access is forbidden to anonymous users for obvious reasons.  From a
security standpoint, it could be allowed for authenticated users, but there
remains a technical obstacle: the absence of a terminal driver for the
connection.

6.3. External and/or non-Kermit Protocols

External protocols such as Zmodem can not be expected to perform any of the
logging or security functions that are done by C-Kermit itself within its
protocol and file modules.  Thus external protocols are disabled in the IKSD.
Plus the fact that such protocols are likely to be incompatible with Telnet
connections in the first place.  In more detail:

 . When the user is 'anonymous' the file system is chroot'd, which means
   that any external executables must exist in the chroot'd file system.
   This leaves open the possibility that executables might be replaced by a
   different file of the same name that has been uploaded either on top of
   the existing file or just into the same directory.  If "." is in the
   PATH for the process anything the user uploads with the name 'rz' or
   'sz' might be executed in its place.  Therefore, the IKSD does not use
   any external commands of any kind.  Not 'ls', not 'cp', not 'df', not
   anything.  To allow the execution of external programs is a major
   security hole in this setting.

 . Most implementations of 'sz' and 'rz' are designed for remote use over a
   terminal connection.  They expect to be run underneath a pseudoterminal
   (PTY).  When IKSD is running there is no PTY.  In fact, when IKSD is
   running there is only a raw socket; the IKSD handles all necessary
   Telnet protocol translations including Telnet Network Virtual Terminal
   (NVT) rules regarding quoting of Carriage Return and 0xFF depending upon
   the state of the BINARY Telnet option in each direction.  'sz' and 'rz'
   are completely incapable of performing these translations in either
   direction and any attempt to transfer a file with them will result in a
   transfer failure and the corruption of the data stream.

 . IKSD supports encrypted sessions, in which case it handles the
   encryption and decryption itself; an external protocol module would not
   do this, and so could not be used on encrypted channels in any case.

6.4. Additional Administrative Controls

Certain options available in wu-ftpd are not implemented in iksd:

 . Ability to select IKSD logging for real vs anonymous users.
 . Ability to select IKSD logging for inbound vs outbound files.
     - Currently all transfers are logged or not logged.

 . Ability to allow/restrict chmod/delete/overwrite for anonymous users.
     - Currently there is no command for changing file permissions.    
     - Guests may not delete files, period.
     - FILE COLLISION is set to RENAME for guests and may not be changed
       since all the other options allow existing files to be altered.
     - There is no way to grant these capabilities to guests.

 . Ability to allow directory creation by anonymous users.
     - Anonymous users may not create or remove directories.

 . Ability to allow/specify CD messages on a per-directory basis.
 . RFC931 authentication of remote (client) user (but wu-ftpd doesn't either).