ftpaccess.5

wu-ftpd类unix下的ftp服务器,可用于嵌入式系统

.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)