FTPD(8) 						      System Manager's Manual							   FTPD(8)

NAME

       ftpd - DARPA Internet File Transfer Protocol server

SYNOPSIS

       /usr/libexec/ftpd [ -d ] [ -l ] [ -ttimeout ] [ -Tmaxtimeout ]

DESCRIPTION

       Ftpd  is  the  DARPA Internet File Transfer Protocol server process.  The server uses the TCP protocol and listens at the port specified in
       the ``ftp'' service specification; see services(5).

       If the -d option is specified, debugging information is written to the syslog.

       If the -l option is specified, each ftp session is logged in the syslog.

       The ftp server will timeout an inactive session after 15 minutes.  If the -t option is specified, the inactivity timeout period will be set
       to  timeout  seconds.   A client may also request a different timeout period; the maximum period allowed may be set to timeout seconds with
       the -T option.  The default limit is 2 hours.

       The ftp server currently supports the following ftp requests; case is not distinguished.

       Request	      Description
       ABOR	      abort previous command
       ACCT	      specify account (ignored)
       ALLO	      allocate storage (vacuously)
       APPE	      append to a file
       CDUP	      change to parent of current working directory
       CWD	      change working directory
       DELE	      delete a file
       HELP	      give help information
       LIST	      give list files in a directory (``ls -lgA'')
       MKD	      make a directory
       MDTM	      show last modification time of file
       MODE	      specify data transfer mode
       NLST	      give name list of files in directory
       NOOP	      do nothing
       PASS	      specify password
       PASV	      prepare for server-to-server transfer
       PORT	      specify data connection port
       PWD	      print the current working directory
       QUIT	      terminate session
       REST	      restart incomplete transfer
       RETR	      retrieve a file
       RMD	      remove a directory
       RNFR	      specify rename-from file name
       RNTO	      specify rename-to file name
       SITE	      non-standard commands (see next section)
       SIZE	      return size of file
       STAT	      return status of server
       STOR	      store a file
       STOU	      store a file with a unique name
       STRU	      specify data transfer structure
       SYST	      show operating system type of server system
       TYPE	      specify data transfer type
       USER	      specify user name
       XCUP	      change to parent of current working directory (deprecated)
       XCWD	      change working directory (deprecated)
       XMKD	      make a directory (deprecated)
       XPWD	      print the current working directory (deprecated)
       XRMD	      remove a directory (deprecated)

       The following non-standard or UNIX specific commands are supported by the SITE request.

       Request	      Description
       UMASK	      change umask. E.g. SITE UMASK 002
       IDLE	      set idle-timer. E.g. SITE IDLE 60
       CHMOD	      change mode of a file. E.g. SITE CHMOD 755 filename
       HELP	      give help information. E.g. SITE HELP

       The remaining ftp requests specified in Internet RFC 959 are recognized, but not implemented.  MDTM and SIZE are not specified in RFC  959,
       but will appear in the next updated FTP RFC.

       The  ftp server will abort an active file transfer only when the ABOR command is preceded by a Telnet "Interrupt Process" (IP) signal and a
       Telnet "Synch" signal in the command Telnet stream, as described in Internet RFC 959.  If a STAT command is received during a  data  trans-
       fer, preceded by a Telnet IP and Synch, transfer status will be returned.

       Ftpd  interprets  file  names  according  to  the ``globbing'' conventions used by csh(1).  This allows users to utilize the metacharacters
       ``*?[]{}~''.

       Ftpd authenticates users according to three rules.

       1)     The user name must be in the password data base, /etc/passwd, and not have a null password.  In this case a password  must  be  pro-
	      vided by the client before any file operations may be performed.

       2)     The user name must not appear in the file /etc/ftpusers.

       3)     The user must have a standard shell returned by getusershell(3).

       4)     If the user name is ``anonymous'' or ``ftp'', an anonymous ftp account must be present in the password file (user ``ftp'').  In this
	      case the user is allowed to log in by specifying any password (by convention this is given as the client host's name).

       In the last case, ftpd takes special measures to restrict the client's access privileges.  The server performs a chroot(2) command  to  the
       home  directory	of  the  ``ftp''  user.  In order that system security is not breached, it is recommended that the ``ftp'' subtree be con-
       structed with care;  the following rules are recommended.

       ~ftp)  Make the home directory owned by ``ftp'' and unwritable by anyone.

       ~ftp/bin)
	      Make this directory owned by the super-user and unwritable by anyone.  The program ls(1) must be present to support  the	list  com-
	      mand.  This program should have mode 111.

       ~ftp/etc)
	      Make  this  directory owned by the super-user and unwritable by anyone.  The files passwd(5) and group(5) must be present for the ls
	      command to be able to produce owner names rather than numbers.  The password field in passwd is not used,  and  should  not  contain
	      real encrypted passwords.  These files should be mode 444.

       ~ftp/pub)
	      Make  this  directory  mode  777	and  owned by ``ftp''.	Users should then place files which are to be accessible via the anonymous
	      account in this directory.

SEE ALSO

       ftp(1), getusershell(3), syslogd(8)

BUGS

       The anonymous account is inherently dangerous and should avoided when possible.

       The server must run as the super-user to create sockets with privileged port numbers.  It maintains an effective user id of the	logged	in
       user,  reverting  to the super-user only when binding addresses to sockets.  The possible security holes have been extensively scrutinized,
       but are possibly incomplete.

4.2 Berkeley Distribution					 February 23, 1989							   FTPD(8)