xref: /original-bsd/libexec/ftpd/ftpd.8 (revision 0eaa7944)
Copyright (c) 1983 Regents of the University of California.
All rights reserved. The Berkeley software License Agreement
specifies the terms and conditions for redistribution.

@(#)ftpd.8 6.1 (Berkeley) 04/27/85

FTPD 8C ""
C 5
NAME
ftpd - DARPA Internet File Transfer Protocol server
SYNOPSIS
/etc/ftpd [ -d ] [ -l ] [ -t timeout ]
DESCRIPTION
Ftpd is the DARPA Internet File Transfer Prototocol 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, each socket created will have debugging turned on (SO_DEBUG). With debugging enabled, the system will trace all TCP packets sent and received on a socket. The program trpt (8C) may then be used to interpret the packet traces.

If the -l option is specified, each ftp session is logged on the standard output. This allows a line of the form `/etc/ftpd -l > /tmp/ftplog'' to be used to conveniently maintain a log of ftp sessions.

The ftp server will timeout an inactive session after 60 seconds. If the -t option is specified, the inactivity timeout period will be set to timeout .

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

Request Description
ACCT specify account (ignored)
ALLO allocate storage (vacuously)
APPE append to a file
CWD change working directory
DELE delete a file
HELP give help information
LIST give list files in a directory (``ls -lg'')
MODE specify data transfer mode
NLST give name list of files in directory (``ls'')
NOOP do nothing
PASS specify password
PORT specify data connection port
QUIT terminate session
RETR retrieve a file
RNFR specify rename-from file name
RNTO specify rename-to file name
STOR store a file
STRU specify data transfer structure
TYPE specify data transfer type
USER specify user name
XCUP change to parent of current working directory
XCWD change working directory
XMKD make a directory
XPWD print the current working directory
XRMD remove a directory

The remaining ftp requests specified in Internet RFC 765 are recognized, but not implemented.

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 provided by the client before any file operations may be performed.
2)
The user name must not appear in the file /etc/ftpusers .
3)
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 constructed 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 commands. 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 work properly. 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(1C),
BUGS
There is no support for aborting commands.

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.