NAME
ftpaccess - ftpd configuration file
Description
The ftpaccess file is used to configure the operation of ftpd(8).
Access Capabilities
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 getgrent(2) library routine
uses).
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:
class rmtuser real !*.example.com
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.
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.
guestgroup <groupname> [<groupname> ...]
guestuser <username> [<username> ...]
realgroup <groupname> [<groupname> ...]
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 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 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:
guest1:<passwd>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
When guest1 successfully logs in, the ftp server will
chroot("/ftp") and then chdir("/incoming"). The guest user will
only be able to access the directory structure under /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:
guestuser *
realgroup admin
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.
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.
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.
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.
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.
timeout accept <seconds>
timeout connect <seconds>
timeout data <seconds>
timeout idle <seconds>
timeout maxidle <seconds>
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.
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 raw parameter applies
the limit to the total traffic rather than just data files.
data-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. The optional raw parameter applies
the limit to total traffic rather than just data files.
limit-time {*|anonymous|guest} <minutes>
Limit the total time a session can take. By default, there is no
limit. Real users are never limited.
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.
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.
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:
noretrieve /etc/passwd core
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:
noretrieve /etc /home/*/.htaccess
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.
allow-retrieve [absolute|relative] [class=<classname>]... [-]
<filename> ...
Allows retrieval of files which would otherwise be denied by
noretrieve.
loginfails <number>
After <number> login failures, log a "repeated login failures"
message and terminate the FTP connection. Default value is 5.
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:
access_group_name:encrypted_password:real_group_name
where access_group_name is an arbitrary (alphanumeric +
punctuation) string. encrypted_password is the password encrypted
via crypt(3), exactly like in /etc/passwd. real_group_name is the
name of a valid group listed in /etc/group.
NOTE: For this option to work for anonymous FTP users, the ftp
server must keep /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.
Informational Capabilities
greeting full|brief|terse
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.
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.
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).
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.
email <name>
Defines the email address of the ftp archive maintainer. This
string will be printed every time the %E magic cookie is used.
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:
%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
ratios:
%xu Uploaded bytes
%xd Downloaded bytes
%xR Upload/Download ratio (1:n)
%xc Credit bytes
%xT Time limit (minutes)
%xE Elapsed time since login (minutes)
%xL Time left
%xU Upload limit
%xD Download limit
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.
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.
Logging Capabilities
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).
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.
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).
log syslog
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.
Upload/Download ratios
In order for any of these commands to work, you must compile WU-FTPD
with --enable-ratios.
ul-dl-rate <rate> [<class> ...]
Specify Upload/Download ratio (1:rate). When ftp user uploaded 1
bytes, (s)he can take <rate> bytes. By default, there is no
ratio.
dl-free <filename> [<class> ...]
The file <filename> can be downloaded freely (=ignoring the ratio)
dl-free-dir <dirname> [<class> ...]
All files in the directory <dirname> and its subdirectories can be
downloaded freely (=ignoring the ratio) Note that both dl-free and
dl-free-dir are relative to the system’s root, not the chroot
environment.
Miscellaneous Capabilities
alias <string> <dir>
Defines an alias, <string>, for a directory. Can be used to add
the concept of logical directories.
For example:
alias rfc: /pub/doc/rfc
would allow the user to access /pub/doc/rfc from any directory by
the command "cd rfc:". Aliases only apply to the cd command.
cdpath <dir>
Defines an entry in the cdpath. This defines a search path that is
used when changing directories.
For example:
cdpath /pub/packages
cdpath /.aliases
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:
cd foo
the directory will be searched for in the following order:
./foo
an alias called "foo"
/pub/packages/foo
/.aliases/foo
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.
compress <yes|no> <classglob> [<classglob> ...]
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.
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:
<year> <month> <day> <hour> <minute> <deny_offset> <disc_offset>
<text>
where
<year> is any year > 1970
<month> 0-11 <---- LOOK!
<hour> 0-23
<minute> 0-59
<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:
%s time system is going to shut down
%r time new connections will be denied
%d time current connections will be dropped
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.
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.
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 root of the filesystem
for this virtual server, the banner presented to the user when
connecting to this virtual server, or the logfile where transfers
are recorded for this virtual server. If the 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.
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>.
virtual <address> allow <username> [<username> ...]
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.
virtual <address> private
Normally, anonymous users are allowed to log in on the virtual
server. This option denies them access.
virtual <address> passwd <file>
Use a different passwd file for the virtual domain. The daemon
needs to be compiled with --enable-passwd (or OTHER_PASSWD) for
this option to work.
virtual <address> shadow <file>
Use a different shadow file for this virtual domain. The daemon
needs to be compiled with --enable-passwd (or OTHER_PASSWD) for
this option to work.
defaultserver deny <username> [<username> ...]
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.
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.
passive address <externalip> <cidr>
Allows control of the address reported in response to a PASV
command. When any control connection matching the <cidr> requests
a passive data connection (PASV), the <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:
passive address 10.0.1.15 10.0.0.0/8
passive address 192.168.1.5 0.0.0.0/0
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.
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
<cidr> a port in the range <min> to <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.
<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.
pasv-allow <class> [<addrglob> ...]
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.
lslong <command> [<options> ...]
lsshort <command> [<options> ...]
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.
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).
incmail <emailaddress>
virtual <address> incmail <emailaddress>
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.
mailfrom <emailaddress>
virtual <address> mailfrom <emailaddress>
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.
Permission Capabilities
chmod <yes|no> <typelist>
delete <yes|no> <typelist>
overwrite <yes|no> <typelist>
rename <yes|no> <typelist>
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.
passwd-check <none|trivial|rfc822> (<enforce|warn>)
Define the level and enforcement of password checking done by the
server for anonymous ftp.
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.
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.
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:
path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9._]*$ ^\. ^-
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.
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:
upload /var/ftp * no
upload /var/ftp /incoming yes ftp daemon 0666
upload /var/ftp /incoming/gifs yes jlc guest 0600 nodirs
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.
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:
throughput /e/ftp * * oo - *
throughput /e/ftp /sw* * 1024 0.5 *
throughput /e/ftp /sw* README oo - *
throughput /e/ftp /sw* * oo - *.foo.com
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>.
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:
anonymous-root /home/ftp
anonymous-root /home/localftp localnet
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.
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:
guest-root /home/users
guest-root /home/staff %100-999 sally
guest-root /home/users/frank/ftp frank
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.
deny-uid <uid-range> [...]
deny-gid <gid-range> [...]
allow-uid <uid-range> [...]
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:
deny-gid %-99 %65535
deny-uid %-99 %65535
allow-gid ftp
allow-uid ftp
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.
restricted-uid <uid-range> [...]
restricted-gid <gid-range> [...]
unrestricted-uid <uid-range> [...]
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:
guest-root /home dick jane
restricted-uid dick jane
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.
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:
site-exec-max-lines 200 remote
site-exec-max-lines 0 local
site-exec-max-lines 25
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.
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.
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.
dns resolveroptions [options]
The resolveroptions option allows you to tweak name server
options. The line takes a series of flags as documented in
resolver(3) (with the leading RES_ removed). Each can be preceded
by an optional + or -. For example,
dns resolveroptions +aaonly -dnsrch
turns on the aaonly option (only accept authoritative answers) and
turns off the dnsrch option (search the domain path).
Files
FTPLIB/ftpaccess
See Also
ftpd(8), umask(2), ftplog(5), ftpconversions(5), ftpshut(8)
ftpaccess(5)