ftpd(1M)ftpd(1M)NAMEftpd - DARPA Internet File Transfer Protocol server
SYNOPSIS
timeout] maxtimeout] umask] size] number_of_tries] nice_value] rootdir]
ctrlport] dataport]
DESCRIPTION
is the DARPA Internet File Transfer Protocol server. It expects to be
run by the Internet daemon (see inetd(1M) and inetd.conf(4)). runs
when a service request is received at the port indicated in the service
specification in (see services(4)).
Options
recognizes the following options and command-line arguments.
Enables the use of the configuration file
(see ftpaccess(4)).
Disables the use of the configuration file
(see ftpaccess(4)).
Sets the buffer size of the data socket to
size blocks of 1024 bytes. The valid range for
size is from 1 to 2097151 (default is 56). A
large buffer size will improve the performance of
on fast links, but may cause long connection
times on slow links (for example, X.25).
If the buffer size needs to be set to any value
other than multiples of 1024 bytes, use "B" imme‐
diately after size without any space. The size
value will be taken in terms of bytes. For exam‐
ple, to set the buffer size to a value equal to
"1500", use
Overrides the control and the data port numbers
respectively that is
used by the daemon. Normally, the
daemon determines the port numbers
by looking in (see services(4)) for
"ftp" and "ftp-data". If there is
no entry for "ftp-data" and the
option is not specified, the daemon
uses the port just prior to the
control connection port. The and
options are both available if run‐
ning as a standalone daemon. Oth‐
erwise, only the option can be
used.
Logs all the files received by
server to (see xferlog(5)). This
option is overridden by the file.
(see ftpaccess(4)).
Enables the use of RFC931 (AUTH/ident) to attempt
to determine the
username on the client.
Applicable only in a secure environment based on
Kerberos V5.
Causes access to be denied if net‐
work authentication fails. See
sis(5).
Causes each FTP session to be logged in the
file.
Logs all commands sent to the
server to be logged to the The
option is overridden by the file
(see ftpaccess(4)). If the option
is used, commands will be logged to
by default.
Specifies the number of tries for a
socket call.
Sets the nice value for an
process. When using this option,
make sure that the nice clause in
file (see ftpaccess(4)) is not
set.
Logs all files transmitted by
to (see xferlog(5)). It logs out‐
going files from the server. This
option is overridden by the file
(see ftpaccess(4)).
The default action of
does not allow usage of reserved
ports as the originating port on
the client's system; that is, the
command cannot specify a reserved
port. This option allows the
client to specify a reserved port.
Note, allowing usage of reserved
ports can result in the misuse of
The security ramifications should
be understood before the option is
turned on.
Enables third party transfer.
Determines whether the daemon uses the PID files.
These files are required by the
directive to determine the number
of current users in each access
class. Disabling the use of the
PID files disables user limits.
The default specifies to use the
PID files. Specify to disable
using the PID files. The option
can be used when testing the server
as a normal user when access per‐
missions prevent the use of the PID
files. Large, busy sites which do
not wish to impose limits on the
number of concurrent users may also
consider disabling the PID files.
Instructs the daemon to chroot (see
chroot(2)) to the specified rootdir
immediately upon loading. This can
improve system security by limiting
the files which may be damaged
should a break-in occur through the
daemon. This option is like anony‐
mous FTP. For this option to work
properly additional files may be
needed under the specified rootdir,
which can vary from system to sys‐
tem.
Runs the daemon in standalone operation mode.
The option runs the daemon in the
background and is useful in startup
scripts during system initializa‐
tion (that is, in The option leaves
the daemon in foreground and is
useful when running from (see
init(1M)).
Causes to timeout inactive sessions after
timeout seconds. By default, ter‐
minates an inactive session after
15 minutes. A timeout value of
implies that there is no timeout
value and is set to an infinite
timeout period. If timeout is set
to a value more than maxtimeout
(see the option), timeout will be
set to the maxtimeout value.
A client can also request a different timeout
period.
The option sets to maxtimeout the
maximum timeout that client can
request, in seconds. By default,
the maximum timeout is 2 hours. A
maxtimeout value of implies that
there is no timeout value and is
set to an infinite timeout period.
Change default umask from 027 to umask.
Disables the use of
and uses for sending data. Use
this option if the link cannot han‐
dle more than one buffer per packet
(for example, Gigabit Ethernet).
The debugging information is written to the
file.
Causes the program to display copyright and ver‐
sion information, then terminate.
Determines whether the user logins are to be
recorded in the
and files. If the option is speci‐
fied, user logins are not recorded
in the wtmps or btmps file. The
default is used to record every
login, logout, and bad login
attempts.
Specifies that the output created by the
and options is not saved to the
file but saved via so that the out‐
put can be collected from several
hosts on one central loghost.
currently supports the following commands (uppercase and
lowercase are interpreted as equivalent):
Abort previous command
Specify account (ignored)
Allocate storage (vacuously)
Append to a file
Change to parent of current working
directory
Change working directory
Delete a file
Sets the server to listen on a data
port and wait for a connection
Use extended address for data con‐
nection
Give help information
Give list files in a directory
Use long address for data connection
Sets the server to listen on a data
port and wait for a connection
Make a directory
Show last modification time of file
Specify data transfer
mode
Give name list of files in directory
Do nothing
Specify password
Prepare for server-to-server trans‐
fer
Specify data connection port
Print the current working directory
Terminate session
Restart incomplete transfer
Retrieve a file
Remove a directory
Specify rename-from file name
Specify rename-to file name
Non-standard commands (see next sec‐
tion)
Return size of file
Return status of server
Store a file
Store a file with a unique name
Specify data transfer
structure
Show operating system type of server
system
Specify data transfer
type
Specify user name
Change to parent of current working
directory
Change working directory
Make a directory
Print the current working directory
Remove a directory
The following commands are supported when
is operating in a secure environment which
is based on Kerberos V5 (see sis(5)).
Command Description
Authentication/security mechanism
Authentication/security data
Clear command channel
Privacy protected command
Integrity protected command
Data channel protection level (level
"C" only)
Protection buffer size (has no
effect)
These commands are described in draft 8 of
the FTP security extensions.
The following non-standard or HP-UX spe‐
cific commands are supported by the com‐
mand:
Change umask (for
example,
Set idle-timer (for
example,
60).
Change mode of a file
(for example,
file‐
name).
Give help information
(for example,
List files newer than
a particular date.
Works like but
gives
extra
infor‐
mation.
Request for special
group access (for
example,
Give special group
access password (for
example,
Execute a program (for
example,
For the command, in order to
execute a program it has to
be placed in the directory.
The program to be executed
must be either a binary pro‐
gram file or a valid shell.
For example for the following
program:
When we give the following
command:
The output will be as fol‐
lows:
The security of the system
will entirely be dependent on
what binaries or shell pro‐
grams that the administrator
has placed in the directory
Making this functionality
available to real users who
have shell access does not
have any major security rami‐
fications, but for anonymous
and guest users who do not
have shell access, it does.
The remaining FTP requests
specified in Internet RFC 959
are recognized, but not
implemented. and are not
specified in RFC 959, but are
expected in the next updated
The FTP server aborts an
active file transfer only
when the 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 receives a command
during a data transfer, pre‐
ceded by a Telnet IP and
Synch, it returns the status
of the transfer.
interprets file names accord‐
ing to the "globbing" conven‐
tions used by This allows
users to utilize the
metacharacters and
authenticates users according
to three rules:
· The user name must be in
the password data base,
and not have a null pass‐
word. The client must
provide the correct pass‐
word for the user before
any file operations can be
performed.
· The user name must not
appear in the file (see
ftpusers(4)).
· The user must have a stan‐
dard shell returned by
Optionally, a system adminis‐
trator can permit public
access or "anonymous FTP."
If this has been set up,
users can access the anony‐
mous FTP account with the
user name or and any non-null
password (by convention, the
client host's name). does a
to the home directory of user
thus limiting anonymous FTP
users' access to the system.
If the user name is or an
anonymous FTP account must be
present in the password file
(user In this case the user
is allowed to log in by spec‐
ifying any password (by con‐
vention this is given as the
user's e-mail address).
In order to permit anonymous
FTP, there must be an entry
in the database for an
account named The password
field should be the group
membership should be and the
login shell should be For
example (assuming the group
ID is
The anonymous FTP directory
should be set up as follows:
The home directory of the FTP
account should be owned by
user
and mode 555 (not
writable). Since
does a to this direc‐
tory, it must have
the following subdi‐
rectories and files:
This directory must
be owned by root and
mode 555 (not
writable).
The file
should be
copied to
This is
needed to
support
directory
listing by
The command
should be
mode 111
(executable
only). If
the FTP
account is
on the same
file system
as can be
hard link,
but it may
not be a
symbolic
link,
because of
the The
command
must be
replaced
when the
system is
updated.
The file
can also be
copied to
the direc‐
tory in
place of
However, if
this is
done, a set
of relevant
libraries
must also
be copied
under the
directory
See the for
details of
required
libraries.
The direc‐
tory must
be owned by
root and
mode 555
(not
writable).
All the
libraries
copied
under this
directory
must be
mode 555
(not
writable).
This directory must
be owned by root and
mode 555 (not
writable).
It should
contain
versions of
the files
passwd and
group. See
passwd(4)
and
group(4).
These files
must be
owned by
root and
mode 444
(readable
only).
These files
must be
present for
the command
to be able
to produce
owner names
rather than
numbers.
This file should con‐
tain entries for the
user and
any other
users who
own files
under the
anonymous
directory.
Such
entries
should have
for pass‐
words.
Group IDs
must be
listed in
the anony‐
mous FTP
group file,
The path
names of
home direc‐
tories in
must be
with
respect to
the anony‐
mous FTP
home direc‐
tory.
This file should con‐
tain the group names
associated with
any group
IDs in file
and any
group IDs
of files in
the anony‐
mous FTP
subdirecto‐
ries.
This directory is
used by anonymous FTP
users to deposit
files
on the sys‐
tem. It
should be
owned by
user and
should be
mode 777
(readable
and
writable by
all).
Directories used to
make files available
to anonymous FTP
users
should be
mode 555
(not
writable),
and any
files to be
distributed
should be
owned by
root and
mode 444
(readable
only) so
that they
cannot be
modified or
removed by
anonymous
FTP users.
The steps that are followed
to create an anonymous
account are used to create a
guest account also.
DIAGNOSTICS
replies to FTP commands to
ensure synchronization of
requests and actions during
file transfers, and to indi‐
cate the status of Every com‐
mand produces at least one
reply, although there may be
more than one. A reply con‐
sists of a three-digit num‐
ber, a space, some text, and
an end of line. The number
is useful for programs; the
text is useful for users.
The number must conform to
this standard, but the text
can vary.
The first digit of the mes‐
sage indicates whether the
reply is good, bad, or incom‐
plete. Five values exist for
the first digit. The values
and the interpretations of
the values are:
1 The requested
action is
being initi‐
ated; expect
another reply
before pro‐
ceeding with a
new command.
2 The requested
action is com‐
plete. The
server is
ready for a
new request.
3 The command
has been
accepted, but
the requested
action
requires more
information.
4 The command
was not
accepted, the
requested
action failed,
but the error
condition is
temporary and
the action can
be requested
again.
5 The command
was not
accepted, the
requested
action failed,
and the error
condition
would most
likely occur
again if the
same command
sequence is
repeated.
The second digit indicates
the functional area that the
message addresses. The val‐
ues of the second digit and
the interpretations of these
values are:
0 Syntax. A
message with a
0 for the sec‐
ond digit
indicates that
a syntax error
occurred.
1 Information.
A message with
a 1 as the
second digit
indicates that
the message is
in reply to a
request for
information.
2 Connections.
A message with
a 2 as the
second digit
indicates that
the message is
a reply to a
request for
control and
data connec‐
tion informa‐
tion.
3 Authentication
and account‐
ing. A mes‐
sage with a 3
as the second
digit indi‐
cates that the
message is a
reply to a
login or
accounting
procedure.
4 Not currently
specified.
5 File system.
A message with
a 5 as the
second digit
indicates that
the text fol‐
lowing the
number con‐
tains informa‐
tion concern‐
ing the status
of the server
file system.
The third digit provides a
further clarification of the
information supplied by the
second digit. Following are
several examples of messages.
Note that replies match the
number but not the text.
110 Restart marker
reply. MARK
where yyyy is
a user process
data stream
marker, and
mmmm is equiv‐
alent marker
120 Service ready
in nnn minutes
200 Command okay
211 System status,
or system help
reply
212 Directory sta‐
tus
230 User logged
in, proceed
250 Requested file
action okay,
completed
331 User name
okay, need
password
350 Requested file
action pending
further infor‐
mation
425 Cannot open
data connec‐
tion
451 Requested
action
aborted: local
error in pro‐
cessing
500 Syntax error,
command unrec‐
ognized or
command line
too long
530 Not logged in
550 Requested
action not
taken; file
unavailable,
not found, no
access
GENERAL FTP EXTENSIONS
There are some extensions to
the FTP server such that if
the user specifies a filename
(when using a RETRIEVE com‐
mand), the following actions
will occur:
True Filename Specified Filename Action
──────────────────────────────────────────────────────────────────
filename.Z filename Decompress (uncompress) file
before transmitting
filename filename.Z Compress filename
before transmitting
filename filename.tar Tar filename
before transmitting
filename filename.tar.Z Tar and compress filename
before transmitting
Also, the FTP server will
attempt to check for valid e-
mail addresses and notify the
user if invalid e-mail
addresses are found. For
users whose FTP client will
hang on "long replies" (that
is, multiline responses),
using a dash as the first
character of the password
will disable this "long
replies" feature.
Users whose password starts
with a dash, have to use an
extra dash in the beginning
of the password for login to
succeed. However, the "long
replies" feature will be dis‐
abled in this case.
The FTP server can also log
all file transmission and
reception, keeping the fol‐
lowing information for each
file transmission that takes
place.
1 current time
in the form
DDD MMM dd
hh:mm:ss YYYY
2 transfer time
in seconds
3 remote host
name
4 file size in
bytes
5 name of file
6 transfer type
(a>scii,
b>inary)
7 special action
flags (con‐
catenated as
needed):
C
file was com‐
pressed
U
file was
uncompressed
T
file was
tar'ed
_ no
action taken
8 file was sent
to user
(o>utgoing) or
received from
user (i>ncom‐
ing)
9 accessed
anonymously
(r>eal,
a>nonymous,
g>uest)
10 local username
or, if guest,
ID string
given (anony‐
mous FTP pass‐
word)
11 service name
("ftp", other)
12 authentication
method (bit‐
mask)
0
none
1
RFC931 Authen‐
tication
13 authenticated
user id (if
available, "*"
otherwise)
WARNINGS
The password is sent unen‐
crypted through the socket
connection.
Anonymous FTP is inherently
dangerous to system security.
DEPENDENCIES
Pluggable Authentication Modules
(PAM)
PAM is an Open Group standard
for user authentication,
password modification, and
validation of accounts. In
particular, is invoked to
perform all functions related
to login. This includes
retrieving the password, val‐
idating the account, and dis‐
playing error messages.
supports only a single pass‐
word, unlike the and com‐
mands. will not work prop‐
erly if it uses multiple mod‐
ules in the file.
AUTHOR
was developed by the Univer‐
sity of California, Berkeley
and the Washington Univer‐
sity, St. Louis, Missouri.
SEE ALSOftp(1), inetd(1M), chroot(2),
send(2), sendfile(2),
pam_authenticate(3), getuser‐
shell(3C), ftpaccess(4),
ftpusers(4), group(4),
inetd.conf(4), passwd(4),
sis(5), xferlog(5).
ftpd(1M)
