ftpaccess.5
ftpaccess(5) ftpaccess(5)
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 <group
name>. 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 "guest
group" 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 addi
tional 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 work
ing nameserver. It may also be the name of a file,
starting with a slash ('/'), which contains addi
tional 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 direc
tory 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 pro
cess 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 overrid
den 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) con
versation. Setting this to zero (0) completely dis
ables the daemon's use of this protocol. The infor
mation 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>, display
ing <message_file> if the user is denied access.
Limit check is performed at login time only. If mul
tiple "limit" commands can apply to the current ses
sion, 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-get
table, 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-directo
ries may be retrieved. Also, no files named '.htac
cess' 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 mem
bers of particular classes. If any class= is speci
fied 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 perma
nently 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 nec
essary 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 ver
sion. '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 main
tainer. 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 notifica
tion.
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 direc
tory 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 modi
fied 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 anony
mous 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 "anony
mous", "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 anony
mous 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 out
going 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 com
pile 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 (=ignor
ing the ratio)
dl-free-dir <dirname> [<class> ...]
All files in the directory <dirname> and its subdi
rectories 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 envi
ronment.
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 directo
ries. 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/ftpconver
sions.
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 connec
tions are dropped at a specified time before shut
down. <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 connec
tions will be denied and existing connections will be
disconnected.
<text> follows the normal rules for any message (see
"message"), with the following additional magic cook
ies 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 con
figuration file.
The external program ftpshut(8) can be used to auto
mate 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 fea
ture. 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 discour
aged 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 lis
tens 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 dae
mon to listen on. This feature allows firewalls to
limit the ports which remote clients may use to con
nect 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 con
nections 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 speci
fication of the command and options used to generate
directory listings. Note the options cannot contain
spaces and the defaults for these clauses are gener
ally 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 anony
mous 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 anony
mous uploads on that host. Otherwise, notifications
will be sent to the global addresses.
Defaultserver addresses only apply when the FTP ses
sion 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 speci
fied. 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 speci
fied 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> {<disal
lowed 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 /incom
ing/gifs. Files that were uploaded to /incoming
would be owned by ftp/daemon and would have permis
sions 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 fol
lowed 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 direc
tory. 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 com
plete 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 deter
mine 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 speci
fied 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 val
ues 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 direc
tory /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 exam
ple, try not to rely solely upon the ftp restric
tions. 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 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 mes
sage file), admonishing the user. If the optional over
ride is specified, allow the connection after complain
ing.
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), ftp
shut(8)
ftpaccess(5)