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.


            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

            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.

       0.5i iptos   control|data   [lowdelay|throughput|reliabil­
            ity|mincost ...]

            Set the IP Type of Service  options  for  either  the
            control   or  data  connection.   Options  are  OR'ed
            together.

            Previous versions of the daemon  used  the  following
            options:
                iptos control lowdelay
                iptos  data  throughput  and, while no longer the
            default, these are the recommended settings.

            (generally no options).

       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

            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
            access.   If  used  without  <hostname>,  denies  all
            anonymous  access to this site.  More than one <host­
            name> may be specified.  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

            in the UUCP L.sys file.

       host-limit <class> <n> <times> <message_file>

            Limit <class> to  <n>  simultaneous  connections  per
            host  IP  address  at times <times>, displaying <mes­
            sage_file> if the user is denied access.  Limit check
            is  performed at login time only.  If multiple "host-
            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=<class­
            name>]|[user=<user­        name>]) ... [-] <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.

            The  noretrieve  restrictions  may  be  placed   upon

            the named files are not retrievable.

       allow-retrieve        [absolute|relative]
            ([class=<class­      name>]|[user=<username>])... [-]
            <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.

            If  no  parameter  is  given, the default is "no" and
            SITE GROUP/GPASS will not be honored.

            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


            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.

       signoff full|brief|terse

       signoff text <message>

            Allows  you  to control how much information is given
            out when the remote user logs out.  'signoff full' is
            the  default  and  shows the transfer counts (if com­
            piled into the daemon), and a thank-you message show­
            ing  the host name.  'signoff brief' whose shows only
            the thank-you message.  'signoff terse'  simply  says
            "Goodbye."   Although  full  is the default, terse is
            recommended.

            The 'text' form allows you  to  specify  any  signoff
            message  you  desire.   <message>  can be any string;
            whitespace (spaces and tabs) is converted to a single
            space.

       stat full|brief|terse

       stat text|brieftext <message>

            Allows  you  to control how much information is given
            out when the remote user requests the server's status
            (the  STAT  command).  'stat full' is the default and
            shows the hostname  and  daemon  version  along  with
            transfer  counts  (if compiled in) and quota informa­
            tion (also,  if  compiled  in).   quota  information.
            'stat terse' shows only the connection status with no
            hostname.  Although full is  the  default,  brief  is
            recommended.

            The  'text' and 'brieftext' forms allows you to spec­
            ify any text you desire to appear where  the  version
            information would be displayed.  <message> can be any
            string; whitespace (spaces and tabs) is converted  to
            a single space.


            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

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

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

            If  no typelist is given, commands are logged for all
            users.

       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.

            If no typelist is given, transfers are logged in both
            directions for all users.  If a typelist is given and
            no directions, transfers are logged  in  both  direc­
            tions for the given user types only.

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

            for all users.

       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


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

       tar <yes|no> [<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.

            If no parameters are given, the default is "yes"  and
            compress/tar  conversion  will  be  allowed.   If  no
            classes are given, all classes are  affected;  other­
            wise compress/tar will only be available to the spec­
            ified classes.

       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

            shutdown.  <path> points to a file structured as fol­
            lows:
                <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.

       logfile <path>

            Specifies the transfer log  file  (xferlog)  for  the
            default server.  Virtual hosts can override this with
            the virtual logfile option.  If  omitted,  a  default
            log file is used.

       virtual <address> <root|banner|logfile> <path>

            Enables  the  virtual  ftp  server  capabilities. The
            <address> is the ip address of  the  virtual  server.

            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  log­
            file  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.


            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>

            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.  The full pathname for  the  com­
            mand  must  be  specified  (it  is executed directly,
            without searching any PATH environment  directories),
            and the options cannot contain spaces.

            The lslong command is used when the FTP client issues
            the LIST command and the user is  anonymous  and  the

            not "-" (which is used to indicate the client  cannot
            handle multi-line replies).

            The  lsshort command is used if the FTP client issues
            the LIST command and the other two  requirements  for
            lslong are not met.  For many systems, the lslong and
            lsshort commands and options may be identical.

            The lsplain command  is  used  when  the  FTP  client
            issues the NLST command.

            Note  that  the defaults for these clauses are gener­
            ally correct; use lslong, lsshort or lsplain to over­
            ride these 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>


       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, anonymous users are NOT
            allowed and all others are.

            <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

            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 reg­ exp> ...}

            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=<class­
            name>]|[user=<user­        name>])... [-]  <root-dir>
            <dirglob>  <yes|no>  <owner>  <group>          <mode>
            ["dirs"|"nodirs"] [<d_mode>] [<dirowner> <dirgroup>]

            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

            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  parameters  <dirowner>  and  <dirgroup>
            specify the ownership of the new directory.  If omit­
            ted, the <owner> and <group> parameters are  used  as
            above.   If specified as "*" the directory is created
            with the ownership of the parent directory.

            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>' or
            'user=<username>' restrictions in any order.  If  any
            class  restrictions are specified, this upload clause
            only takes effect if the current user is a member  of
            one of the classes.  If any username restrictions are
            specified this upload clause only  takes  effect  for
            those users.

            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

            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

            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> [...]


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

            NB:  You  cannot  use  deny-uid  or  deny-gid to deny
            anonymous access.  Use defaultserver private (or vir­
            tual .. private) to deny anonymous access.

       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

            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_

            -.  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),  xferlog(5),  ftpconversions(5),  ftp­
       shut(8)


Man(1) output converted with man2html