Ftp客户端

开发平台：
Unix_Linux

ftpaccess.5：源码内容
							."
." Copyright (c) 1999 WU-FTPD Development Group. 
." All rights reserved.
." 
." Portions Copyright (c) 1980, 1985, 1988, 1989, 1990, 1991, 1993, 1994 
." The Regents of the University of California.  Portions Copyright (c) 
." 1993, 1994 Washington University in Saint Louis.  Portions Copyright 
." (c) 1996, 1998 Berkeley Software Design, Inc.  Portions Copyright (c) 
." 1998 Sendmail, Inc.  Portions Copyright (c) 1983, 1995, 1996, 1997 Eric 
." P. Allman.  Portions Copyright (c) 1989 Massachusetts Institute of 
." Technology.  Portions Copyright (c) 1997 Stan Barber.  Portions 
." Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997 Free Software 
." Foundation, Inc.  Portions Copyright (c) 1997 Kent Landfield. 
."
." Use and distribution of this software and its source code are governed 
." by the terms and conditions of the WU-FTPD Software License ("LICENSE"). 
."
."     $Id: ftpaccess.5,v 1.22 1999/09/28 15:12:25 wuftpd Exp $
."
.TH ftpaccess 5
.SH Name
ftpaccess - ftpd configuration file
.SH Description
The ftpaccess file is used to configure the operation of
.BR ftpd(8) .
.SH Access Capabilities
.TP 0.5i
.B autogroup <groupname> <class> [<class> ...]
If an ANONYMOUS user is a member of any of <class>, the ftp server will
perform a setegid() to <groupname>.  This allows access to
group-and-owner-read-only files and directories to a particular class of
anonymous users. <groupname> is a valid group from /etc/group (or wherever
mechanism your
.IR getgrent(2)
library routine uses).
.TP 0.5i
.B class <class> <typelist> <addrglob> [<addrglob> ...]
Define <class> of users, with source addresses of the form <addrglob>.
Multiple members of <class> may be defined.  There may be multiple "class"
commands listing additional members of the class.  If multiple "class"
commands can apply to the current session, the first one listed in the
access file is used.  Failing to define a valid class for a host will cause
access to be denied.  <typelist> is a comma-separated list of any of the
keywords "anonymous", "guest" and "real".  If the "real" keyword is
included, the class can match users using FTP to access real accounts, and
if the "anonymous" keyword is included the class can match users using
anonymous FTP.  The "guest" keyword matches guest access accounts (see
"guestgroup" for more information)
<addrglob> may be a globbed domain name or a globbed numeric address.  It
may also be the name of a file, starting with a slash ('/'), which contains
additional address globs, as well as in the form address:netmask or
address/cidr.
Placing an exclamation (!) before an <addrglob> negates the test.  For
example:
.nf
    class rmtuser real !*.example.com
.fi
will classify real users from outside the example.com domain as the class
rmtuser.  Use care with this option.  Remember, the result of each test is
OR'ed with other tests on the line.
.TP 0.5i
.B deny <addrglob> <message_file>
Always deny access to host(s) matching <addrglob>.  <message_file> is
displayed.  <addrglob> may be "!nameserved" to deny access to sites without
a working nameserver.  It may also be the name of a file, starting with a
slash ('/'), which contains additional address globs, as well as in the
form address:netmask or address/cidr.
.TP 0.5i
.B guestgroup <groupname> [<groupname> ...]
.TP 0.5i
.B guestuser <username> [<username> ...]
.TP 0.5i
.B realgroup <groupname> [<groupname> ...]
.TP 0.5i
.B realuser <username> [<username> ...]
For guestgroup, if a REAL user is a member of any of <groupname>, the
session is set up exactly as with anonymous FTP.  In other words, a
chroot() is done, and the user is no longer permitted to issue the USER and
PASS commands.  <groupname> is a valid group from /etc/group (or whatever
mechanism your
.IR getgrent(3)
library routine uses).
The user's home directory must be properly set up, exactly as anonymous FTP
would be.  The home directory field of the passwd entry is divided into two
directories.  The first field is the root directory which will be the
argument to the
.IR chroot(2)
call.  The second half is the user's home directory relative to the root
directory.  The two halves are separated by a "/./".
For example, in /etc/passwd, the real entry:
.nf
    guest1:<passwd>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
.fi
When guest1 successfully logs in, the ftp server will
.BR chroot("/ftp")
and then
.BR chdir("/incoming") .
The guest user will only be able to access the directory structure under
.BR /ftp
(which will look and act as / to guest1), just as an anonymous FTP user would.
The group name may be specified by either name or numeric ID.  To use a
numeric group ID, place a '%' before the number.  Ranges may be given.  Use
an asterisk to mean all groups.
guestuser works like guestgroup, except uses the user name (or numeric ID).
realuser and realgroup have the same syntax, but reverse the effect of
guestuser and guestgroup.  They allow real user access when the remote user
would otherwise be determined a guest.
For example:
.nf
    guestuser *
    realgroup admin
.fi
causes all non-anonymous users to be treated as guest, with the sole
exception of users in the admin group who are granted real user access.
.TP 0.5i
.B nice <nice-delta> [<class>]
Adjust the process nice value of the ftpd server process by the indicated
<nice-delta> value if the remote user is a member of the named <class>.  If
<class> is not specified, then use <nice-delta> as the default adjustment
to the ftpd server process nice value.  This default nice value adjustment
is used to adjust the nice value of the server process only for those users
who do not belong to any class for which a class-specific `nice' directive
exists in the ftpaccess file.
.TP 0.5i
.B defumask <umask> [<class>]
Set the umask applied to files created by daemon if the remote use is a
member of the named class.  If <class> is not specified, then use the umask
as the default for classes which do not have one specified.
.TP 0.5i
.B tcpwindow <size> [<class>]
Set the TCP window size for the data connection.  This can be used to
control network traffic.  For instance, slow PPP dialin links may need
smaller TCP windows to speed up throughput.  If you don't know what this
does, don't play with it.
.TP 0.5i
.B keepalive <yes|no>
Set the TCP SO_KEEPALIVE option for data sockets.  This can be used to control
network disconnect.  Yes: set it.  No: use system default (usually off).  You
probably want to set this.
.TP 0.5i
.B timeout accept <seconds>
.TP 0.5i
.B timeout connect <seconds>
.TP 0.5i
.B timeout data <seconds>
.TP 0.5i
.B timeout idle <seconds>
.TP 0.5i
.B timeout maxidle <seconds>
.TP 0.5i
.B timeout RFC931 <seconds>
Set various timeouts.
Accept (default 120 seconds): how long the daemon will wait for an incoming
(PASV) data connection.
Connect (default 120 seconds): how long the daemon will wait attempting to
establish an outgoing (PORT) data connection.  This effects the actual
connetion attempt.  The daemon makes several attempts, sleeping a while
between each, before completely giving up.
Data (default 1200 seconds): how long the daemon will wait for some
activity on the data connection.  You should keep this long because the
remote client may have a slow link and there can be quite a bit of data
queued for the client.
Idle (default 900 seconds): how long the daemon will wait for the next
command.  The default can also be overridden by the command line -a option.
This access clause overrides both.
MaxIdle (default 1200 seconds): the SITE IDLE command allows the remote
client to establish a higher value for the idle timeout.  This sets the
upper limit the client may request.  The default can also be overridden by
the command line -A option.  This access clause overrides both.
RFC931 (default 10 seconds): the maximum time the daemon allows for the
entire RFC931 (AUTH/ident) conversation.  Setting this to zero (0)
completely disables the daemon's use of this protocol.  The information
obtained via RFC931 is recorded in the system logs and not actually used in
any authentication.
.TP 0.5i
.B file-limit [<raw>] <in|out|total> <count> [<class>]
Limit the number of data files a user in the given class may transfer.  The
limit may be placed on files in, out or total.  If no class is specified,
the limit is the default for classes which do not have a limit specified.
The optional
.B raw
parameter applies the limit to the total traffic rather than just data
files.
.TP 0.5i
.B byte-limit [<raw>] <in|out|total> <count> [<class>]
Limit the number of data bytes a user in the given class may transfer.  The
limit may be place on bytes in, out or total.  If no class is specified,
the limit is the default for classes which do not have a limit specified.
Note that this limit will preventtransfers once it has been exceeded, but
will not terminate a transfer in progress.  The optional
.B raw
parameter applies the limit to total traffic rather than just data files.
.TP 0.5i
.B limit-time {*|anonymous|guest} <minutes>
Limit the total time a session can take.  By default, there is no limit.
Real users are never limited.
.TP 0.5i
.B guestserver [<hostname>]
Controls which hosts may be used for anonymous or guest access.  If used
without <hostname>, denies all guest or anonymous access to this site.
More than one <hostname> may be specified.  Guest and anonymous access will
only be allowed on the named machines.  If access is denied, the user will
be asked to use the first <hostname> listed.
.TP 0.5i
.B limit <class> <n> <times> <message_file>
Limit <class> to <n> users at times <times>, displaying <message_file> if
the user is denied access.  Limit check is performed at login time only.
If multiple "limit" commands can apply to the current session, the first
applicable one is used.  Failing to define a valid limit, or a limit of -1,
is equivalent to unlimited. <times> is in same format as the times in the
UUCP L.sys file.
.TP 0.5i
.B noretrieve [absolute|relative] [class=<classname>] ... [-] <filename> <filename> ...
Always deny retrieve-ability of these files.  If the files are a path
specification (i.e. begins with '/' character) then only those files are marked
un-gettable, otherwise all files with matching the filename are refused
transfer.  For example:
.nf
    noretrieve /etc/passwd core
.fi
specifies no one will be able to get the file /etc/passwd whereas they will
be allowed to transfer a file `passwd' if it is not in /etc. On the other
hand no one will be able to get files named `core' wherever they are.
Directory specifications mark all files and sub-directories in the named
directory un-gettable.  The <filename> may be specified as a file glob.  For
example:
.nf
    noretrieve /etc /home/*/.htaccess
.fi
specified no files in /etc or any of its sub-directories may be retrieved.
Also, no files named '.htaccess' anywhere under the /home directory may be
retrieved.
The optional first parameter selects whether names are intepreted as
absolute or relative to the current chroot'd environment.  The default is
to intepret names beginning with a slash as absolute.
The noretrieve restrictions may be placed upon members of particular
classes.  If any class= is specified the named files are only
non-retrievable if the current user is a member of any of the given
classes.
.TP 0.5i
.B allow-retrieve [absolute|relative] [class=<classname>]... [-] <filename> ...
Allows retrieval of files which would otherwise be denied by noretrieve.
.TP 0.5i
.B loginfails <number>
After <number> login failures, log a "repeated login failures" message and
terminate the FTP connection.  Default value is 5.
.TP 0.5i
.B private <yes|no>
After user logs in, the SITE GROUP and SITE GPASS commands may be used to
specify an enhanced access group and associated password.  If the group
name and password are valid, the user becomes (via setegid()) a member of
the group specified in the group access file /etc/ftpgroups.
The format of the group access file is:
.nf
    access_group_name:encrypted_password:real_group_name
.fi
where access_group_name is an arbitrary (alphanumeric + punctuation)
string.  encrypted_password is the password encrypted via
.IR crypt(3) ,
exactly like in
.BR /etc/passwd .
.B real_group_name
is the name of a valid group listed in
.BR /etc/group .
NOTE: For this option to work for anonymous FTP users, the ftp server must
keep
.B /etc/group
permanently open and the group access file is loaded into memory.  This
means that (1) the ftp server now has an additional file descriptor open,
and (2) the necessary passwords and access privileges granted to users via
SITE GROUP will be static for the duration of an FTP session.  If you have
an urgent need to change the access groups and/or passwords *NOW*, you just
kill all of the running FTP servers.
.SH Informational Capabilities
.TP 0.5i
.B greeting full|brief|terse
.TP 0.5i
.B greeting text <message>
Allows you to control how much information is given out before the remote
user logs in.  'greeting full' is the default and shows the hostname and
daemon version.  'greeting brief' whose shows the hostname.  'greeting
terse' simply says "FTP server ready."  Although full is the default, brief
is recommended.
The 'text' form allows you to specify any greeting message you desire.
<message> can be any string; whitespace (spaces and tabs) is converted to a
single space.
.TP 0.5i
.B banner <path>
Works similarly to the message command, except that the banner is displayed
before the user enters the username/password.  The <path> is relative to
the real system root, not the base of the anonymous FTP directory.
.B WARNING:
use of this command can completely prevent non-compliant FTP clients from
making use of the FTP server.  Not all clients can handle multi-line
responses (which is how the banner is displayed).
.TP 0.5i
.B hostname <some.host.name>
Defines the default host name of the ftp server.  This string will be
printed on the greeting message and every time the %L magic cookie is used.
The host name for virtual servers overrides this value.  If not specified,
the default host name for the local machine is used.
.TP 0.5i
.B email <name>
Defines the email address of the ftp archive maintainer.  This string will
be printed every time the %E magic cookie is used.
.TP 0.5i
.B message <path> {<when> {<class> ...}}
Define a file with <path> such that ftpd will display the contents of the
file to the user login time or upon using the change working directory
command.  The <when> parameter may be "LOGIN" or "CWD=<dir>".  If <when> is
"CWD=<dir>", <dir> specifies the new default directory which will trigger
the notification.
The optional <class> specification allows the message to be displayed only
to members of a particular class.  More than one class may be specified.
There can be "magic cookies" in the readme file which cause the ftp server
to replace the cookie with a specified text string:
.nf
    %T      local time (form Thu Nov 15 17:12:42 1990)
    %F      free space in partition of CWD (kbytes)
              [not supported on all systems]
    %C      current working directory
    %E      the maintainer's email address as defined in ftpaccess
    %R      remote host name
    %L      local host name
    %u      username as determined via RFC931 authentication
    %U      username given at login time
    %M      maximum allowed number of users in this class
    %N      current number of users in this class
    %B      absolute limit on disk blocks allocated
    %b      preferred limit on disk blocks
    %Q      current block count
    %I      maximum number of allocated inodes (+1)
    %i      preferred inode limit
    %q      current number of allocated inodes
    %H      time limit for excessive disk use
    %h      time limit for excessive files
.fi
The message will only be displayed once to avoid annoying the user.
Remember that when MESSAGEs are triggered by an anonymous FTP user, the
<path> must be relative to the base of the anonymous FTP directory tree.
.TP 0.5i
.B readme <path> {<when> {<class>}}
Define a file with <path> such that ftpd will notify user at login time or
upon using the change working directory command that the file exists and
was modified on such-and-such date.  The <when> parameter may be "LOGIN" or
"CWD=<dir>".  If <when> is "CWD=<dir>", <dir> specifies the new default
directory which will trigger the notification.  The message will only be
displayed once, to avoid bothering users.  Remember that when README
messages are triggered by an anonymous FTP user, the <path> must be
relative to the base of the anonymous FTP directory tree.
The optional <class> specification allows the message to be displayed only
to members of a particular class.  More than one class may be specified.
.SH Logging Capabilities
.TP 0.5i
.B log commands <typelist>
Enables logging of individual commands by users.  <typelist> is a
comma-separated list of any of the keywords "anonymous", "guest" and
"real".  If the "real" keyword is included, logging will be done for users
using FTP to access real accounts, and if the "anonymous" keyword is
included logging will done for users using anonymous FTP.  The "guest"
keyword matches guest access accounts (see "guestgroup" for more
information).
.TP 0.5i
.B log transfers <typelist> <directions>
Enables logging of file transfers for either real or anonymous FTP users.
Logging of transfers TO the server (incoming) can be enabled separately
from transfers FROM the server (outbound).  <typelist> is a comma-separated
list of any of the keywords "anonymous", "guest" and "real".  If the "real"
keyword is included, logging will be done for users using FTP to access
real accounts, and if the "anonymous" keyword is included logging will done
for users using anonymous FTP. The "guest" keyword matches guest access
accounts (see "guestgroup" for more information).  <directions> is a
comma-separated list of any of the two keywords "inbound" and "outbound",
and will respectively cause transfers to be logged for files sent to the
server and sent from the server.
.TP 0.5i
.B log security <typelist>
Enables logging of violations of security rules (noretrieve, .notar, ...)
for real, guest and/or anonymous users.  <typelist> is a comma-separated
list of any of the keywords "anonymous", "guest" and "real".  If the "real"
keyword is included, logging will be done for users using FTP to access
real accounts, and if the "anonymous" keyword is included logging will done
for users using anonymous FTP. The "guest" keyword matches guest access
accounts (see "guestgroup" for more information).
.TP 0.5i
.B log syslog
.TP 0.5i
.B log syslog+xferlog
Redirects the logging messages for incoming and outgoing transfers to
syslog.  Without this option the messages are written to xferlog.
syslog+xferlog sends the transfer log messages to both the system log and
the xferlog.
.SH Miscellaneous Capabilities
.TP 0.5i
.B alias <string> <dir>
Defines an alias, <string>, for a directory.  Can be used to add the
concept of logical directories.
For example:
.nf
    alias rfc: /pub/doc/rfc
.fi
would allow the user to access /pub/doc/rfc from any directory by the
command "cd rfc:".  Aliases only apply to the cd command.
.TP 0.5i
.B cdpath <dir>
Defines an entry in the cdpath. This defines a search path that is used
when changing directories.
For example:
.nf
    cdpath /pub/packages
    cdpath /.aliases
.fi
would allow the user to cd into any directory directly under /pub/packages
or /.aliases directories. The search path is defined by the order the lines
appear in the ftpaccess file.
If the user were to give the command:
.nf
    cd foo
.fi
the directory will be searched for in the following order:
.nf
    ./foo
    an alias called "foo"
    /pub/packages/foo
    /.aliases/foo
.fi
The cd path is only available with the cd command. If you have a large
number of aliases you might want to set up an aliases directory with links
to all of the areas you wish to make available to users.
.TP 0.5i
.B compress <yes|no> <classglob> [<classglob> ...]
.TP 0.5i
.B tar <yes|no> <classglob> [<classglob> ...]
Enables compress or tar capabilities for any class matching any of
<classglob>.  The actual conversions are defined in the external file
FTPLIB/ftpconversions.
.TP 0.5i
.B shutdown <path>
If the file pointed to by <path> exists, the server will check the file
regularly to see if the server is going to be shut down.  If a shutdown is
planned, the user is notified, new connections are denied after a specified
time before shutdown and current connections are dropped at a specified
time before shutdown.  <path> points to a file structured as follows:
.nf
    <year> <month> <day> <hour> <minute> <deny_offset> <disc_offset>
    <text>
.fi
where
.nf
    <year> is any year > 1970
    <month> 0-11 <---- LOOK!
    <hour> 0-23
    <minute> 0-59
.fi
<deny_offset> and <disc_offset> are the offsets in HHMM format
before the shutdown time that new connections will be denied and existing
connections will be disconnected.
<text> follows the normal rules for any message (see "message"), with the
following additional magic cookies available:
.nf
    %s      time system is going to shut down
    %r      time new connections will be denied
    %d      time current connections will be dropped
.fi
all times are in the form: ddd MMM DD hh:mm:ss YYYY.  There can be only one
"shutdown" command in the configuration file.
The external program ftpshut(8) can be used to automate the process of
generating this file.
.TP 0.5i
.B daemonaddress <address>
If the value is not set, then the server will listen for connections on
every IP addresses, otherwise it will only listen on the IP address
specified.
Use of this clause is discouraged.  It was added to support a single site's
needs.  It will completely break virtual hosting and the syntax is likely
to change in a future version of the daemon.
.TP 0.5i
.B virtual <address> <root|banner|logfile> <path>
Enables the virtual ftp server capabilities. The <address> is the ip
address of the virtual server. The second argument specifies that the
<path> is either the path to the
.B root
of the filesystem for this virtual server, the
.B banner
presented to the user when connecting to this virtual server, or the
.B logfile
where transfers are recorded for this virtual server. If the
.B logfile
is not specified the default logfile will be used.  All other message
files and permissions as well as any other settings in this file apply to
all virtual servers.
NOTE: Your operating system may not support this feature. It has been
tested on BSD/OS, Solaris 2.X and Linux.
The <address> may also be specified as the hostname rather than the IP
number.  This is strongly discouraged since, if DNS is not available at the
time the FTP session begins, the hostname will not be matched.
.TP 0.5i
.B virtual <address> <hostname|email> <string>
Sets the hostname shown in the greeting message and STATus command, or the
email address used in message files and on the HELP command, to the given
<string>.
.TP 0.5i
.B virtual <address> allow <username> [<username> ...]
.TP 0.5i
.B virtual <address> deny <username> [<username> ...]
Normally, real and guest users are not allowed to log in on the vitual
server unless they are guests and chroot'd to the virtual root.  The users
listed on the virtual allow line(s) will be granted access.  All users can
be granted access by giving '*' as the username.  The virtual deny clauses
are processed after the virtual allow clauses and are used to deny access
to specific users when all users were allowed.
.TP 0.5i
.B virtual <address> private
Normally, anonymous users are allowed to log in on the virtual server.
This option denies them access.
.TP 0.5i
.B defaultserver deny <username> [<username> ...]
.TP 0.5i
.B defaultserver allow <username> [<username> ...]
Normally, all users are allowed access to the default (non-virtual) FTP
server.  Use defaultserver deny to revoke access for specific users;
specify '*' to deny access to all users.  Specific users can then be
allowed using defaultserver allow.
.TP 0.5i
.B defaultserver private
Normally, anonymous users are allowed on the default (non-virtual) FTP
server.  This statement disallows anonymous access.
The virtual and defaultserver allow, deny and private clauses provide a
means to control which users are allowed access on which FTP servers.
.TP 0.5i
.B passive address <externalip> <cidr>
Allows control of the address reported in response to a PASV command.  When
any control connection matching the
.B <cidr>
requests a passive data connection (PASV), the
.B <externalip>
address is reported.  NOTE: this does not change the address the daemone
actually listens on, only the address reported to the client.  This feature
allows the daemon to operate correctly behind IP-renumbering firewalls.
For example:
.nf
    passive address 10.0.1.15   10.0.0.0/8
    passive address 192.168.1.5 0.0.0.0/0
.fi
Clients connecting from the class-A network 10 will be told the passive
connection is listening on IP-address 10.0.1.15 while all others will be
told the connection is listening on 192.168.1.5
Multiple passive addresses may be specified to handle complex, or
multi-gatewayed, networks.
.TP 0.5i
.B passive ports <cidr> <min> <max>
Allows control of the TCP port numbers which may be used for a passive data
connection.  If the control connection matches the
.B <cidr>
a port in the range
.B <min>
to
.B <max>
will be randomly selected for the daemon to listen on.  This feature allows
firewalls to limit the ports which remote clients may use to connect into
the protected network.
.B <cidr>
is shorthand for an IP address in dotted-quad notation followed by a slash
and the number of left-most bits which represent the network address (as
opposed to the machine address).  For example, if you're using the reserved
class-A network 10, instead of a netmask of 255.0.0.0 use a CIDR of /8 as
in 10.0.0.0/8 to represent your network.
.TP 0.5i
.B pasv-allow <class> [<addrglob> ...]
.TP 0.5i
.B port-allow <class> [<addrglob> ...]
Normally, the daemon does not allow a PORT command to specify an address
different than that of the control connection.  And it does not allow a
PASV connection from another address.
The port-allow clause provides a list of addresses which the specified
class of user may give on a PORT command.  These addresses will be allowed
even if they do not match the IP-address of the client-side of the control
connection.
The pasv-allow clause provides a list of addresses which the specified
class of user may make data connections from.  These addresses will be
allowed even if they do not match the IP-address of the client-side of the
control connection.
.TP 0.5i
.B lslong <command> [<options> ...]
.TP 0.5i
.B lsshort <command> [<options> ...]
.TP 0.5i
.B lsplain <command> [<options> ...]
The lslong, lsshort and lsplain clauses allow specification of the command
and options used to generate directory listings.  Note the options cannot
contain spaces and the defaults for these clauses are generally correct;
use lslong, lsshort or lsplain only if absolutely necessary.
.TP 0.5i
.B mailserver <hostname>
Specify the name of a mail server which will accept upload notifications
for the FTP daemon.  Multiple mail servers may be listed; the daemon will
attempt to deliver the upload notification to each, in order, until one
accepts the message.  If no mail servers are specified, localhost is used.
This option is only meaningful if anyone is to be notified of anonymous
uploads (see incmail).
.TP 0.5i
.B incmail <emailaddress>
.TP 0.5i
.B virtual <address> incmail <emailaddress>
.TP 0.5i
.B defaultserver incmail <emailaddress>
Specify email addresses to be notified of anonymous uploads.  Mutltiple
addresses can be specified; each will receive a notification.  If none are
specified, no notifications are sent.
If addresses are specified for a virtual host, only those addresses will
receive notification up anonymous uploads on that host.  Otherwise,
notifications will be sent to the global addresses.
Defaultserver addresses only apply when the FTP session is not using one of
the virtual hosts.  In this way, you can receive notifications for your
default anonymous area, but not see notifications to virtual hosts which do
not have their own notifications.
.TP 0.5i
.B mailfrom <emailaddress>
.TP 0.5i
.B virtual <address> mailfrom <emailaddress>
.TP 0.5i
.B defaultserver mailfrom <emailaddress>
Specify the sender's email address for anonymous upload notifications.
One one address may be specified.  If no mailfrom applies, email is sent
from the default mailbox name 'wu-ftpd'.  To avoid problems if the
recipient attempts to reply to a notification, or if downstream mail
problems generate bounces, you should ensure the mailfrom address is
deliverable.
.SH Permission Capabilities
.TP 0.5i
.B chmod <yes|no> <typelist>
.TP 0.5i
.B delete <yes|no> <typelist>
.TP 0.5i
.B overwrite <yes|no> <typelist>
.TP 0.5i
.B rename <yes|no> <typelist>
.TP 0.5i
.B umask <yes|no> <typelist>
Allows or disallows the ability to perform the specified function.  By
default, all users are allowed.
<typelist> is a comma-separated list of any of the keywords "anonymous",
"guest", "real" and "class=".  When "class=" appears, it must be followed
by a classname.  If any class= appears, the <typelist> restriction applies
only to users in that class.
.TP 0.5i
.B passwd-check <none|trivial|rfc822> (<enforce|warn>)
Define the level and enforcement of password checking done by the server
for anonymous ftp.
.nf
    none      no password checking performed.
    trivial   password must contain an '@'.
    rfc822    password must be an rfc822 compliant address.
    warn      warn the user, but allow them to log in.
    enforce   warn the user, and then log them out.
.fi
.TP 0.5i
.B deny-email <case-insensitive-email-address>
Consider the e-mail address given as an argument as invalid. If
passwd-check is set to enforce, anonymous users giving this address as
password cannot log in.  That way, you can stop users from having stupid
WWW browsers use fake addresses like IE?0User@ or mozilla@. (by using this,
you are not shutting out users using a WWW browser for ftp - you just make
them configure their browser correctly.) Only one address per line, but you
can have as many deny-email addresses as you like.
.TP 0.5i
.B path-filter <typelist> <mesg> <allowed_charset> {<disallowed regexp> ...}
For users in <typelist>, path-filter defines regular expressions that
control what a filename can or can not be.  There may be multiple
disallowed regexps.  If a filename is invalid due to failure to match the
regexp criteria, <mesg> will be displayed to the user.  For example:
.nf
    path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9._]*$ ^\. ^-
.fi
specifies that all upload filenames for anonymous users must be made of
only the characters A-Z, a-z, 0-9, and "._-" and may not begin with a "."
or a "-".  If the filename is invalid, /etc/pathmsg will be displayed to
the user.
.TP 0.5i
.B upload [absolute|relative] [class=<classname>]... [-] <root-dir> <dirglob> <yes|no> <owner> <group> <mode> ["dirs"|"nodirs"] [<d_mode>]
Define a directory with <dirglob> that permits or denies uploads.
If it does permit uploads, all newly created files will be owned by <owner>
and <group> and will have their permissions set according to <mode>,
existing files which are overwritten will keep their original ownership and
permissions.
Directories are matched on a best-match basis.
For example:
.nf
    upload /var/ftp *              no
    upload /var/ftp /incoming      yes ftp daemon 0666
    upload /var/ftp /incoming/gifs yes jlc guest  0600 nodirs
.fi
would only allow uploads into /incoming and /incoming/gifs.  Files that
were uploaded to /incoming would be owned by ftp/daemon and would have
permissions of 0666.  File uploaded to /incoming/gifs would be owned by
jlc/guest and have permissions of 0600. Note that the <root-dir> here must
match the home directory specified in the password database for the "ftp"
user.
The optional "dirs" and "nodirs" keywords can be specified to allow or
disallow the creation of new subdirectories using the mkdir command.
Note that if the upload command is used, directory creation is allowed by
default. To turn it off by default, you must specify a user, group and mode
followed by the "nodirs" keyword as the first line where the upload command
is used in this file.
If directories are permitted, the optional <d_mode> determines the
permissions for a newly created directory.  If <d_mode> is omitted, the
permissions are inferred from <mode> or are 0777 if <mode> is also omitted.
The upload keyword only applies to users who have a home directory (the
argument to the chroot() ) of <root-dir>.  <root-dir> may be specified as
"*" to match any home directory.
The <owner> and/or <group> may each be specified as "*", in which case any
uploaded files or directories will be created with the ownership of the
directory in which they are created.
The optional first parameter selects whether <root-dir> names are
intepreted as absolute or relative to the current chroot'd environment.
The default is to intepret <root-dir> names as absolute.
You can specify any number of 'class=<classname>' restrictions.  If any are
specified, this upload clause only takes effect if the current user is a
member of one of the classes.
Please read the upload.configuration.HOWTO for a complete discussion of how
to configure your server to allow uploading files.
.TP 0.5i
.B throughput <root-dir> <subdir-glob> <file-glob-list> <bytes-per-second> <bytes-per-second-multiply> <remote-glob-list>
Define files via comma-seperated <file-glob-list> in subdir matched by
<subdir-glob> under <root-dir> that have restricted transfer throughput of
<bytes-per-second> on download when the remote hostname or remote IP
address matches the comma-seperated <remote-glob-list>.
Entries are matched on a best-match basis.
For example:
.nf
    throughput /e/ftp *    *      oo   -   *
    throughput /e/ftp /sw* *      1024 0.5 *
    throughput /e/ftp /sw* README oo   -   *
    throughput /e/ftp /sw* *      oo   -   *.foo.com
.fi
would set maximum throughput per default, but restrict download to 1024
bytes/s for any files under /e/ftp/sw/ which are not named README.  The only
exceptions are remote hosts from within the domain foo.com which always get
maximum throughput.  Every time a remote client has retrieved a file under
/e/ftp/sw/ the bytes per seconds of the matched entry line are internally
multiplied by a factor, here 0.5.  So when the remote client retrieves its
second file it is served with 512 bytes/s, the third time with only 254
bytes/s, the fourth time with only 128 bytes/s and so on.
The string "oo" for the bytes per second field means no throughput
restriction.  A multiply factor of 1.0 or "-" means no change of the
throughput after every successful transfer.
Note that the <root-dir> here must match the home directory specified in
the password database for the "ftp" user.  The throughput keyword only
applies to users who have a home directory (the argument to the chroot() )
of <root-dir>.
.TP 0.5i
.B anonymous-root <root-dir> [<class>]
<root-dir> specifies the chroot() path for anonymous users.  If no
anonymous-root is matched, the old method of parsing the home directory for
the 'ftp' user is used.  If no <class> is specified, this is the root
directory for anonymous users who do not any other anonymous-root
specification.  Multiple classes may be given on the line.  If an
anonymous-root is chosen for the user, the 'ftp' user's home directory in
the <root-dir>/etc/passwd file is used to determine the initial directory
and the 'ftp' user's home directory in the system-wide /etc/passwd is not
used.
For example:
.nf
    anonymous-root /home/ftp
    anonymous-root /home/localftp localnet
.fi
causes all anonymous users to be chroot()'d to the directory /home/ftp
then, if the 'ftp' user exists in /home/ftp/etc/passwd, their initial CWD
is that home directory.  Anonymous users in the class localnet, however,
are chroot()'d to the directory /home/localftp and their initial CWD is
taken from the 'ftp' user's home directory in /home/localftp/etc/passwd.
.TP 0.5i
.B guest-root <root-dir> [<uid-range>]
<root-dir> specified the chroot() path for guest users.  If no guest-root
is is matched, the old method of parsing the user's home directory is used.
If no <uid-range> is specified, this is the root directory for guest users
who do not match any other guest-root specification.  Multiple uid ranges
may be given on the line.  If a guest-root is chosen for the user, the
user's home directory in the <root-dir>/etc/passwd file is used to
determine the initial directory and their home directory in the system-wide
/etc/passwd is not used.
<uid-range> specifies numeric UID values.  Ranges are specified by giving
the lower and upper bounds (inclusive), separated by a dash.  Omitting the
lower bound means "all up to", and omitted the upper bound means "all
starting from".
For example:
.nf
    guest-root /home/users
    guest-root /home/staff %100-999 sally
    guest-root /home/users/frank/ftp frank
.fi
causes all guest users to chroot() to /home/users then starts each user in
their home directory specified in /home/users/etc/passwd.  Users in the
range 100 through 999, inclusive, and user sally, will be chroot()'d to
/home/staff and the CWD will be taken from their entries in
/home/staff/etc/passwd.  The single user frank will be chroot()'d to
/home/users/owner/ftp and the CWD will be from his entry in
/home/users/owner/ftp/etc/passwd.
Note that order is important for both anonymous-root and guest-root.  If a
user would match multiple clauses, only the first applies; with the
exception of the clause which has no <class> or <uid-range>, which applies
only if no other clause matches.
.TP 0.5i
.B deny-uid <uid-range> [...]
.TP 0.5i
.B deny-gid <gid-range> [...]
.TP 0.5i
.B allow-uid <uid-range> [...]
.TP 0.5i
.B allow-gid <gid-range> [...]
These clauses allow specification of UID and GID values which will be
denied access to the ftp server.  The allow-uid and allow-gid clauses may
be used to allow access for uid/gid which would otherwise be denied.  These
checks occur before all others.  Deny is checked before allow.  The default
is to allow access.  Note that in most cases, this can remove the need for
an /etc/ftpusers files.  For example:
.nf
    deny-gid %-99 %65535
    deny-uid %-99 %65535
    allow-gid ftp
    allow-uid ftp
.fi
denies ftp access to all privileged or special users and groups on a Linux
box except the anonymous 'ftp' user/group.  In many cases, this can
eliminate the need for the /etc/ftpusers file.  Support for that file still
exists so it may be used when changing /etc/ftpaccess is not desired.
Throughout the ftpaccess file, any place a single UID or GID is allowed,
either names or numbers may be used.  To use numbers, put a '%' before it.
In places where a range is allowed, put the '%' before the range.
.TP 0.5i
.B restricted-uid <uid-range> [...]
.TP 0.5i
.B restricted-gid <gid-range> [...]
.TP 0.5i
.B unrestricted-uid <uid-range> [...]
.TP 0.5i
.B unrestricted-gid <gid-range> [...]
These clauses control whether or not real or guest users will be allowed
access to areas on the FTP site outside their home directories.  They are
not meant to replace the use of guestgroup and guestuser.  Instead, use
these to supplement the operation of guests.  The unrestricted-uid and
unrestricted-gid clauses may be used to allow users outside their home
directories who would otherwise be restricted.
An example of the use of these clauses shows their intended use.  Assume
user 'dick' has a home directory /home/dick and 'jane' /home/jane:
.nf
    guest-root /home dick jane
    restricted-uid dick jane
.fi
While both dick and jane are chroot'd to /home, they cannot access each
other's files because they are restricted to their home directories.
Whereever possible, in situations such as this example, try not to rely
solely upon the ftp restrictions.  As with all other ftp access rules, try
to use directory and file permissions to backstop the operation of the
ftpaccess configuration.
.TP 0.5i
.B site-exec-max-lines <number> [<class> ...]
The SITE EXEC feature traditionally limits the number of lines of output
which may be sent to the remote client.  This clause allows you to set this
limit.  If omitted, the limit is 20 lines.  A limit of 0 (zero) implies no
limit; be very careful if you choose to remove the limit.  If a clause is
found matching the remote user's class, that limit is used.  Otherwise, the
clause with class '*', or no class given, is used.  For example:
.nf
    site-exec-max-lines 200 remote
    site-exec-max-lines 0 local
    site-exec-max-lines 25
.fi
limits output from SITE EXEC (and therefore SITE INDEX) to 200 lines for
'remote' users, specifies there is no limit at all for 'local' users, and
sets a limit of 25 lines for all other users.
.TP 0.5i
.B dns refuse_mismatch <filename> [override]
Refuse FTP sessions when the forward and reverse lookups for the remote
site do not match.  Display the named file (like a message file),
admonishing the user.  If the optional override is specified, allow the
connection after complaining.
.TP 0.5I
.B dns refuse_no_reverse <filename> [override]
Refuse FTP sessions when there is no reverse DNS entry for the remote site.
Display the named file (like a message file), admonishing the user.  If the
optional override is specified, allow the connection after complaining.
.TP 0.5i
.B dns resolveroptions [options]
The resolveroptions option allows you to tweak name server options.  The
line takes a series of flags as documented in
.IR resolver(3)
(with the leading RES_ removed).  Each can be preceded by an optional + or
-.  For example, 
.nf
    dns resolveroptions +aaonly -dnsrch
.fi
turns on the aaonly option (only accept authoritative answers) and turns
off the dnsrch option (search the domain path).
.SH Files
FTPLIB/ftpaccess
.SH See Also
.BR ftpd(8) ,
.BR umask(2) ,
.BR ftplog(5) ,
.BR ftpconversions(5) ,
.BR ftpshut(8)

						