Seth Woolley's Man Viewer

ftpaccess(5) - ftpaccess - ftpd configuration file - man 5 ftpaccess

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

ftpaccess(5)                                                      ftpaccess(5)



Name
       ftpaccess - ftpd configuration file(1,n)


Description
       The ftpaccess file(1,n) is used to configure the operation of ftpd(8).


Access Capabilities
       autogroup <groupname> <class> [<class> ...]

            If an ANONYMOUS user is a member of any of <class>, the ftp server
            will perform a setegid() to <groupname>.  This  allows  access(2,5)  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(1,5), with source addresses of the form  <addr-
            glob(1,3,7,n)>.   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(1,8) the access(2,5) file(1,n) is used.  Failing to define  a
            valid class for a host(1,5) will cause access(2,5) 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(1,5) using FTP to access(2,5)  real  accounts,  and  if(3,n)  the
            "anonymous"  keyword  is  included the class can match users(1,5) using
            anonymous FTP.  The "guest" keyword matches guest access(2,5)  accounts
            (see "guestgroup" for more information)

            <addrglob>  may  be  a  globbed  domain  name or a globbed numeric
            address.  It may also be the name of a file(1,n), starting with a slash
            ('/'),  which contains additional address globs, as well as in(1,8) 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(1,5) 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(2,5) to host(1,5)(s) matching <addrglob>.  <message_file>
            is displayed.  <addrglob> may be "!nameserved" to deny  access(2,5)  to
            sites  without a working nameserver.  It may also be the name of a
            file(1,n), starting with  a  slash  ('/'),  which  contains  additional
            address   globs,  as  well  as  in(1,8)  the  form  address:netmask  or
            address/cidr.


       guestgroup <groupname> [<groupname> ...]

       guestuser <username> [<username> ...]

       realgroup <groupname> [<groupname> ...]

       realuser <username> [<username> ...]

            For guestgroup, if(3,n) a REAL user is a member of any of  <groupname>,
            the  session  is  set(7,n,1 builtins)  up exactly as with anonymous FTP.  In other
            words, a chroot(1,2)() 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(7,n,1 builtins) up, exactly as
            anonymous FTP would be.  The home directory field  of  the  passwd(1,5)
            entry  is  divided  into  two directories.  The first field is the
            root directory which will be the argument to the  chroot(1,2)(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(1,8) /etc/passwd(1,5), the real entry:
                guest1:<passwd(1,5)>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
            When  guest1  successfully  logs   in(1,8),   the   ftp   server   will
            chroot(1,2)("/ftp")  and  then chdir("/incoming").  The guest user will
            only be able to access(2,5) the directory structure under  /ftp  (which
            will  look(1,8,3 Search::Dict)  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(2,5)
            when the remote user would otherwise be determined a guest.

            For example:
                guestuser *
                realgroup admin
            causes  all  non-anonymous  users(1,5) to be treated as guest, with the
            sole exception of users(1,5) in(1,8) the admin group who  are  granted  real
            user access.


       nice(1,2) <nice-delta> [<class>]

            Adjust  the  process  nice(1,2) value of the ftpd server process by the
            indicated <nice-delta> value if(3,n) the remote user is a member of the
            named(5,8) <class>.  If <class> is not specified, then use <nice-delta>
            as the default adjustment to the ftpd server process  nice(1,2)  value.
            This  default  nice(1,2)  value  adjustment  is used to adjust the nice(1,2)
            value of the server process only for those users(1,5) who do not belong
            to any class for which a class-specific `nice(1,2)' directive exists in(1,8)
            the ftpaccess file.


       defumask <umask> [<class>]

            Set the umask applied to files created by daemon if(3,n) the remote use
            is a member of the named(5,8) 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(7,n,1 builtins) it.  No: use system
            default (usually off).  You probably want to set(7,n,1 builtins) this.


       timeout(1,3x,3x cbreak) accept(2,8) <seconds>

       timeout(1,3x,3x cbreak) connect <seconds>

       timeout(1,3x,3x cbreak) data <seconds>

       timeout(1,3x,3x cbreak) idle <seconds>

       timeout(1,3x,3x cbreak) maxidle <seconds>

       timeout(1,3x,3x cbreak) 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(1,2) 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(2,5) clause overrides both.

            MaxIdle (default 1200 seconds): the SITE IDLE command  allows  the
            remote  client  to  establish a higher value for the idle timeout.
            This sets the upper limit the client may request.  The default can
            also  be  overridden  by  the command line -A option.  This access(2,5)
            clause overrides both.

            RFC931 (default 10 seconds): the maximum time(1,2,n)  the  daemon  allows
            for  the entire RFC931 (AUTH/ident) conversation.  Setting this to
            zero (0) completely disables the daemon's use  of  this  protocol.
            The information obtained via RFC931 is recorded in(1,8) the system logs
            and not actually used in(1,8) any authentication.


       file-limit [<raw(3x,7,8,3x cbreak)>] <in(1,8)|out|total> <count> [<class>]

            Limit the number of data files a  user  in(1,8)  the  given  class  may
            transfer.   The limit may be placed on files in(1,8), 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(3x,7,8,3x cbreak) parameter applies
            the limit to the total traffic rather than just data files.


       data-limit [<raw(3x,7,8,3x cbreak)>] <in(1,8)|out|total> <count> [<class>]

            Limit the number of data bytes a  user  in(1,8)  the  given  class  may
            transfer.   The  limit may be place on bytes in(1,8), 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(3x,7,8,3x cbreak) parameter applies
            the limit to total traffic rather than just data files.


       limit-time {*|anonymous|guest} <minutes>

            Limit the total time(1,2,n) a session can take.  By default, there is  no
            limit.  Real users(1,5) 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(2,5)
            to  this  site.  More than one <hostname> may be specified.  Guest
            and anonymous access(2,5) will only be allowed on the  named(5,8)  machines.
            If  access(2,5)  is  denied,  the  user  will be asked to use the first
            <hostname> listed.


       limit <class> <n> <times> <message_file>

            Limit <class> to <n> users(1,5)  at  times  <times>,  displaying  <mes-
            sage_file> if(3,n) the user is denied access.  Limit check is performed
            at login(1,3,5) time(1,2,n) only.  If multiple "limit" commands can apply to the
            current  session,  the  first  applicable one is used.  Failing to
            define a valid limit, or a limit of -1, is  equivalent  to  unlim-
            ited.  <times>  is  in(1,8)  same format as the times in(1,8) the UUCP L.sys
            file.


       noretrieve [absolute|relative] [class=<classname>] ...  [-]  <filename>
       <filename> ...

            Always deny retrieve-ability of these files.  If the files  are  a
            path  specification  (i.e.  begins  with  '/' character) then only
            those files are  marked  un-gettable,  otherwise  all  files  with
            matching the filename are refused transfer.  For example:
                noretrieve /etc/passwd(1,5) core
            specifies  no one will be able to get the file(1,n) /etc/passwd(1,5) whereas
            they will be allowed to transfer a file(1,n) `passwd(1,5)' if(3,n) it is  not  in(1,8)
            /etc.  On  the  other  hand no one will be able to get files named(5,8)
            `core' wherever they are.

            Directory specifications mark all files and sub-directories in(1,8) the
            named(5,8) directory un-gettable.  The <filename> may be specified as a
            file(1,n) glob.  For example:
                noretrieve /etc /home/*/.htaccess
            specified no files in(1,8) /etc or any of its  sub-directories  may  be
            retrieved.   Also,  no  files named(5,8) '.htaccess' anywhere under the
            /home directory may be retrieved.

            The optional first parameter selects whether names are  intepreted
            as  absolute or relative to the current chroot(1,2)'d environment.  The
            default is to intepret names beginning with a slash as absolute.

            The noretrieve restrictions may be placed upon members of particu-
            lar  classes.  If any class= is specified the named(5,8) files are only
            non-retrievable if(3,n) the current user is a  member  of  any  of  the
            given classes.


       allow-retrieve  [absolute|relative]  [class=<classname>]...  [-] <file-
       name> ...

            Allows retrieval of files which would otherwise be denied by nore-
            trieve.


       loginfails <number>

            After <number> login(1,3,5) failures, log  a  "repeated  login(1,3,5)  failures"
            message and terminate the FTP connection.  Default value is 5.


       private <yes|no>

            After  user logs in(1,8), the SITE GROUP and SITE GPASS commands may be
            used to specify an enhanced access(2,5) group and associated  password.
            If  the  group  name and password are valid, the user becomes (via
            setegid()) a member of the group specified  in(1,8)  the  group  access(2,5)
            file(1,n) /etc/ftpgroups.

            The format of the group access(2,5) file(1,n) is:
                access_group_name:encrypted_password:real_group_name
            where  access_group_name  is an arbitrary (alphanumeric + punctua-
            tion) string.  encrypted_password is the  password  encrypted  via
            crypt(3),  exactly  like  in(1,8)  /etc/passwd(1,5).  real_group_name is the
            name of a valid group listed in(1,8) /etc/group.

            NOTE: For this option to work for anonymous  FTP  users(1,5),  the  ftp
            server  must keep /etc/group permanently open(2,3,n) and the group access(2,5)
            file(1,n) is loaded into memory.  This means that (1)  the  ftp  server
            now  has an additional file(1,n) descriptor open(2,3,n), and (2) the necessary
            passwords and access(2,5) privileges granted to users(1,5)  via  SITE  GROUP
            will be static for the duration of an FTP session.  If you have an
            urgent need to change the access(2,5) groups  and/or  passwords  *NOW*,
            you just kill(1,2,1 builtins) all of the running FTP servers.


Informational Capabilities
       greeting full|brief|terse

       greeting text <message>

            Allows you to control how much information is given out before the
            remote user logs in.  'greeting full' is the default and shows the
            hostname  and  daemon  version.   'greeting brief' whose shows the
            hostname.   'greeting  terse'  simply  says  "FTP  server  ready."
            Although full is the default, brief is recommended.

            The  'text'  form  allows  you to specify any greeting message you
            desire.  <message> can be any string(3,n); 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  dis-
            played).


       hostname <some.host.name>

            Defines the default host(1,5) name of the ftp server.  This string(3,n) will
            be printed on the greeting message and every  time(1,2,n)  the  %L  magic(4,5)
            cookie  is used.  The host(1,5) name for virtual(5,8) servers overrides this
            value.  If not specified, the default  host(1,5)  name  for  the  local
            machine is used.


       email <name>

            Defines  the  email  address  of the ftp archive maintainer.  This
            string(3,n) will be printed every time(1,2,n) the %E magic(4,5) cookie is used.


       message <path> {<when> {<class> ...}}

            Define a file(1,n) with <path> such that ftpd will display the contents
            of  the file(1,n) to the user login(1,3,5) time(1,2,n) or upon using the change work-
            ing directory command.  The <when> parameter  may  be  "LOGIN"  or
            "CWD=<dir>".   If  <when>  is "CWD=<dir>", <dir> specifies the new
            default directory which will trigger the notification.

            The optional <class> specification allows the message to  be  dis-
            played only to members of a particular class.  More than one class
            may be specified.

            There can be "magic(4,5) cookies" in(1,8) the http://advancemame.sourceforge.net .RE This package contains: .RS 4 .PD 0 .HP 4 advzip Recompression and test utility for zip files .HP 4 advpng Recompression utility for png files .HP 4 advmng Recompression utility for mng files .HP 4 advdef Recompression utility for deflate streams in .png, .mng and .gz files .PD .RE" href="/man.cgi/1/readme">readme file(1,n)  which  cause  the
            ftp server to replace the cookie with a specified text string:
                %T      local time(1,2,n) (form Thu Nov 15 17:12:42 1990)
                %F      free space in(1,8) partition of CWD (kbytes)
                          [not supported on all systems]
                %C      current working directory
                %E      the maintainer's email address as defined in(1,8) ftpaccess
                %R      remote host(1,5) name
                %L      local host(1,5) name
                %u      username as determined via RFC931 authentication
                %U      username given at login(1,3,5) time(1,2,n)
                %M      maximum allowed number of users(1,5) in(1,8) this class
                %N      current number of users(1,5) in(1,8) 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(1,2,n) limit for excessive disk use
                %h      time(1,2,n) 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(1,2,n) since login(1,3,5) (minutes)
                %xL     Time left
                %xU     Upload limit
                %xD     Download limit


            The  message  will  only  be  displayed once to avoid annoying the
            user.  Remember that when MESSAGEs are triggered by  an  anonymous
            FTP user, the <path> must be relative to the base of the anonymous
            FTP directory tree.


       http://advancemame.sourceforge.net .RE This package contains: .RS 4 .PD 0 .HP 4 advzip Recompression and test utility for zip files .HP 4 advpng Recompression utility for png files .HP 4 advmng Recompression utility for mng files .HP 4 advdef Recompression utility for deflate streams in .png, .mng and .gz files .PD .RE" href="/man.cgi/1/readme">readme <path> {<when> {<class>}}

            Define a file(1,n) with <path> such that ftpd will notify user at login(1,3,5)
            time(1,2,n)  or  upon using the change working directory command that the
            file(1,n) exists and was modified on such-and-such  date.   The  <when>
            parameter   may   be   "LOGIN"   or  "CWD=<dir>".   If  <when>  is
            "CWD=<dir>", <dir> specifies the new default directory which  will
            trigger  the  notification.   The  message  will only be displayed
            once, to avoid bothering users.  Remember that  when  README  mes-
            sages  are  triggered by an anonymous FTP user, the <path> must be
            relative to the base of the anonymous FTP directory tree.

            The optional <class> specification allows the message to  be  dis-
            played 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(1,5)  using  FTP  to  access(2,5) real accounts, and if(3,n) the
            "anonymous" keyword is included logging will done for users(1,5)  using
            anonymous  FTP.  The "guest" keyword matches guest access(2,5) accounts
            (see "guestgroup" for more information).


       log transfers <typelist> <directions>

            Enables logging of file(1,n) transfers for either real or anonymous FTP
            users.   Logging  of  transfers  TO  the  server (incoming) can be
            enabled separately from  transfers  FROM  the  server  (outbound).
            <typelist>  is  a  comma-separated  list  of  any  of the keywords
            "anonymous",  "guest"  and  "real".   If  the  "real"  keyword  is
            included,  logging will be done for users(1,5) using FTP to access(2,5) real
            accounts, and if(3,n) the "anonymous" keyword is included logging  will
            done  for  users(1,5)  using anonymous FTP. The "guest" keyword matches
            guest access(2,5) 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(1,5) using FTP to access(2,5) real accounts, and if(3,n)
            the "anonymous" keyword is included logging will  done  for  users(1,5)
            using  anonymous  FTP.  The  "guest"  keyword matches guest access(2,5)
            accounts (see "guestgroup" for more information).


       log syslog(2,3,5,3 Sys::Syslog)

       log syslog(2,3,5,3 Sys::Syslog)+xferlog

            Redirects the logging messages for incoming and outgoing transfers
            to  syslog.  Without this option the messages are written to xfer-
            log.

            syslog(2,3,5,3 Sys::Syslog)+xferlog sends the transfer log messages to both the  system
            log and the xferlog.


Upload/Download ratios
       In  order  for  any of these commands to work, you must compile WU-FTPD
       with --enable-ratios.


       ul-dl-rate <rate> [<class> ...]

            Specify Upload/Download ratio (1:rate).  When ftp user uploaded  1
            bytes,  (s)he  can  take  <rate>  bytes.   By default, there is no
            ratio.


       dl-free <filename> [<class> ...]

            The file(1,n) <filename> can be downloaded freely (=ignoring the ratio)


       dl-free-dir <dirname> [<class> ...]

            All files in(1,8) the directory <dirname> and its subdirectories can be
            downloaded freely (=ignoring the ratio) Note that both dl-free and
            dl-free-dir  are  relative  to  the  system's root, not the chroot(1,2)
            environment.



Miscellaneous Capabilities
       alias <string(3,n)> <dir>

            Defines an alias, <string(3,n)>, 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(2,5) /pub/doc/rfc from any directory by
            the command "cd rfc:".  Aliases only apply to the cd command.


       cdpath <dir>

            Defines an entry in(1,8) the cdpath. This defines a search path that is
            used when changing directories.

            For example:
                cdpath /pub/packages
                cdpath /.aliases
            would  allow  the  user  to  cd  into any directory directly under
            /pub/packages or /.aliases directories. The search path is defined
            by the order the lines appear in(1,8) the ftpaccess file.

            If the user were to give the command:
                cd foo
            the directory will be searched for in(1,8) 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(7,n,1 builtins) up an aliases direc-
            tory  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(1,8) the external
            file(1,n) FTPLIB/ftpconversions.


       shutdown(2,8) <path>

            If the file(1,n) pointed to by <path> exists, the server will check the
            file(1,n)  regularly to see if(3,n) the server is going to be shut down.  If
            a shutdown(2,8) is planned, the user is notified, new  connections  are
            denied  after a specified time(1,2,n) before shutdown(2,8) and current connec-
            tions are dropped at a specified  time(1,2,n)  before  shutdown.   <path>
            points to a file(1,n) 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(1,8) HHMM format
            before the shutdown(2,8) time(1,2,n) that new connections will be  denied  and
            existing connections will be disconnected.

            <text>  follows  the normal rules for any message (see "message"),
            with the following additional magic(4,5) cookies available:
                %s      time(1,2,n) system is going to shut down
                %r      time(1,2,n) new connections will be denied
                %d      time(1,2,n) current connections will be dropped
            all times are in(1,8) the form: ddd MMM DD hh:mm:ss YYYY.  There can be
            only one "shutdown(2,8)" command in(1,8) the configuration file.

            The  external  program  ftpshut(8)  can  be  used  to automate the
            process of generating this file.


       daemonaddress <address>

            If the value is not set(7,n,1 builtins), then the server will listen(1,2,7)  for  connec-
            tions  on every IP addresses, otherwise it will only listen(1,2,7) on the
            IP address specified.

            Use of this clause is discouraged.  It was added to support a sin-
            gle  site's  needs.   It will completely break virtual(5,8) hosting and
            the syntax is likely to change in(1,8) a future version(1,3,5) of the  daemon.


       virtual(5,8) <address> <root|banner|logfile> <path>

            Enables  the virtual(5,8) ftp server capabilities. The <address> is the
            ip(7,8) address of the virtual(5,8) server. The  second  argument  specifies
            that  the  <path> is either the path to the root of the filesystem
            for this virtual(5,8) server, the banner presented  to  the  user  when
            connecting  to this virtual(5,8) server, or the logfile where transfers
            are recorded for this virtual(5,8) server. If the logfile is not speci-
            fied  the  default  logfile will be used.  All other message files
            and permissions as well as any other settings in(1,8) this  file(1,n)  apply
            to all virtual(5,8) servers.

            NOTE:  Your  operating system may not support this feature. It has
            been tested on BSD/OS, Solaris 2.X and Linux.

            The <address> may also be specified as the  hostname  rather  than
            the  IP number.  This is strongly discouraged since, if(3,n) DNS is not
            available at the time(1,2,n) the FTP session begins,  the  hostname  will
            not be matched.


       virtual(5,8) <address> <hostname|email> <string(3,n)>

            Sets  the  hostname  shown in(1,8) the greeting message and STATus com-
            mand, or the email address used in(1,8) message files and on  the  HELP
            command, to the given <string(3,n)>.


       virtual(5,8) <address> allow <username> [<username> ...]

       virtual(5,8) <address> deny <username> [<username> ...]

            Normally,  real  and  guest users(1,5) are not allowed to log in(1,8) on the
            vitual server unless they are guests and chroot(1,2)'d to  the  virtual(5,8)
            root.   The  users(1,5)  listed  on  the  virtual(5,8) allow line(s) will be
            granted access.  All users(1,5) can be granted access(2,5) by giving '*'  as
            the  username.   The  virtual(5,8) deny clauses are processed after the
            virtual(5,8) allow clauses and are used  to  deny  access(2,5)  to  specific
            users(1,5) when all users(1,5) were allowed.


       virtual(5,8) <address> private

            Normally,  anonymous  users(1,5)  are  allowed to log in(1,8) on the virtual(5,8)
            server.  This option denies them access.


       virtual(5,8) <address> passwd(1,5) <file(1,n)>

            Use a different passwd(1,5) file(1,n) for the  virtual(5,8)  domain.  The  daemon
            needs  to  be  compiled with --enable-passwd (or OTHER_PASSWD) for
            this option to work.


       virtual(5,8) <address> shadow(3,5) <file(1,n)>

            Use a different shadow(3,5) file(1,n) for this virtual(5,8)  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(1,5) are allowed access(2,5) to  the  default  (non-vir-
            tual)  FTP  server.   Use  defaultserver deny to revoke access(2,5) for
            specific users(1,5); specify '*' to deny access(2,5) to all users.  Specific
            users(1,5) can then be allowed using defaultserver allow.


       defaultserver private

            Normally, anonymous users(1,5) are allowed on the default (non-virtual)
            FTP server.  This statement disallows anonymous access.

            The virtual(5,8) and defaultserver allow, deny and private clauses pro-
            vide  a  means  to control which users(1,5) are allowed access(2,5) on which
            FTP servers.


       passive address <externalip> <cidr>

            Allows control of the address reported in(1,8) response to a PASV  com-
            mand.   When any control connection matching the <cidr> requests a
            passive  data  connection  (PASV),  the  <externalip>  address  is
            reported.   NOTE:  this  does  not  change the address the daemone
            actually listens on, only the  address  reported  to  the  client.
            This  feature  allows  the  daemon to operate correctly behind IP-
            renumbering firewalls.

            For example:
                passive address 10.0.1.15   10.0.0.0/8
                passive address 192.168.1.5 0.0.0.0/0
            Clients connecting from the class-A network 10 will  be  told  the
            passive  connection is listening on IP-address 10.0.1.15 while all
            others will be told the connection is listening on 192.168.1.5

            Multiple passive addresses may be specified to handle complex,  or
            multi-gatewayed, networks.


       passive ports <cidr> <min> <max>

            Allows  control  of  the  TCP port numbers which may be used for a
            passive data connection.  If the control  connection  matches  the
            <cidr>  a  port  in(1,8)  the  range  <min>  to  <max> will be randomly
            selected for the daemon to listen(1,2,7) on.  This feature  allows  fire-
            walls  to  limit the ports which remote clients may use to connect
            into the protected network.

            <cidr> is shorthand for an IP address in(1,8) dotted-quad notation fol-
            lowed  by a slash and the number of left-most bits which represent
            the network address (as opposed  to  the  machine  address).   For
            example,  if(3,n) 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(1,8)  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 spec-
            ified class of user may give on a PORT command.   These  addresses
            will  be  allowed  even if(3,n) 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 spec-
            ified  class  of  user  may  make  data  connections  from.  These
            addresses will be allowed even if(3,n) they do not match the IP-address
            of the client-side of the control connection.


       lslong <command> [<options> ...]

       lsshort <command> [<options> ...]

       lsplain <command> [<options> ...]

            The lslong, lsshort and lsplain clauses allow specification of the
            command and options used to generate directory listings.  Note the
            options  cannot  contain spaces and the defaults for these clauses
            are generally correct; use lslong,  lsshort  or  lsplain  only  if(3,n)
            absolutely necessary.


       mailserver <hostname>

            Specify the name of a mail(1,8) server which will accept(2,8) upload notifi-
            cations for the FTP daemon.  Multiple mail(1,8) servers may be  listed;
            the  daemon  will  attempt  to  deliver the upload notification to
            each, in(1,8) order, until one accepts the message.  If no mail(1,8) servers
            are  specified, localhost is used.  This option is only meaningful
            if(3,n) anyone is to be notified of anonymous uploads (see incmail).


       incmail <emailaddress>

       virtual(5,8) <address> incmail <emailaddress>

       defaultserver incmail <emailaddress>

            Specify email addresses  to  be  notified  of  anonymous  uploads.
            Mutltiple  addresses can be specified; each will receive a notifi-
            cation.  If none are specified, no notifications are sent.

            If  addresses  are  specified  for  a  virtual(5,8)  host(1,5),  only  those
            addresses  will  receive notification up anonymous uploads on that
            host.   Otherwise,  notifications  will  be  sent  to  the  global
            addresses.

            Defaultserver  addresses  only  apply  when the FTP session is not
            using one of the virtual(5,8) hosts.  In  this  way,  you  can  receive
            notifications for your default anonymous area, but not see notifi-
            cations to virtual(5,8) hosts which do not  have  their  own  notifica-
            tions.


       mailfrom <emailaddress>

       virtual(5,8) <address> mailfrom <emailaddress>

       defaultserver mailfrom <emailaddress>

            Specify  the sender's email address for anonymous upload notifica-
            tions.  One one address may be specified.  If no mailfrom applies,
            email  is  sent from the default mailbox name 'wu-ftpd'.  To avoid
            problems if(3,n) the recipient attempts to reply to a notification,  or
            if(3,n)  downstream  mail(1,8)  problems generate bounces, you should ensure
            the mailfrom address is deliverable.


Permission Capabilities
       chmod(1,2) <yes|no> <typelist>

       delete <yes|no> <typelist>

       overwrite <yes|no> <typelist>

       rename(1,2,n) <yes|no> <typelist>

       umask <yes|no> <typelist>

            Allows or disallows the ability to perform the specified function.
            By default, all users(1,5) 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(1,5) in(1,8) 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(7,n,1 builtins)  to  enforce,  anonymous  users(1,5)  giving  this
            address  as  password cannot log in.  That way, you can stop users(1,5)
            from having stupid WWW browsers use fake addresses like  IE?0User@
            or  mozilla@. (by using this, you are not shutting out users(1,5) using
            a WWW browser for ftp - you just make them configure their browser
            correctly.)  Only  one  address per line, but you can have as many
            deny-email addresses as you like.


       path-filter <typelist> <mesg>  <allowed_charset>  {<disallowed  regexp(3,n)>
       ...}

            For users(1,5) in(1,8) <typelist>, path-filter defines  regular  expressions
            that control what a filename can or can not be.  There may be mul-
            tiple disallowed regexps.  If a filename is invalid due to failure
            to  match  the  regexp(3,n)  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(1,5)  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> <dir-
       glob(1,3,7,n)> <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(7,n,1 builtins) accord-
            ing to <mode>, existing files  which  are  overwritten  will  keep
            their original ownership and permissions.

            Directories are matched on a best-match basis.

            For example:
                upload /var/ftp *              no
                upload /var/ftp /incoming      yes ftp daemon 0666
                upload /var/ftp /incoming/gifs yes jlc guest  0600 nodirs
            would only allow uploads into /incoming and /incoming/gifs.  Files
            that were uploaded to /incoming would be owned by  ftp/daemon  and
            would  have  permissions of 0666.  File uploaded to /incoming/gifs
            would be owned by jlc/guest and have  permissions  of  0600.  Note
            that  the  <root-dir> here must match the home directory specified
            in(1,8) 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(1,2) command.

            Note that if(3,n) the upload command is  used,  directory  creation  is
            allowed  by default. To turn it off by default, you must specify a
            user, group and mode followed by the "nodirs" keyword as the first
            line where the upload command is used in(1,8) this file.

            If directories are permitted, the optional <d_mode> determines the
            permissions for a newly created directory.  If <d_mode>  is  omit-
            ted,  the  permissions  are  inferred  from  <mode> or are 0777 if(3,n)
            <mode> is also omitted.

            The upload keyword only applies to users(1,5) who have a home directory
            (the  argument to the chroot(1,2)() ) 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(1,8)  which
            case  any  uploaded  files or directories will be created with the
            ownership of the directory in(1,8) which they are created.

            The optional first parameter selects whether <root-dir> names  are
            intepreted  as  absolute or relative to the current chroot(1,2)'d envi-
            ronment.  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(3,n)  the
            current user is a member of one of the classes.

            Please  read(2,n,1 builtins) the upload.configuration.HOWTO for a complete discus-
            sion 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(1,8)   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(7,n,1 builtins) maximum throughput per default, but restrict download to
            1024  bytes/s  for  any files under /e/ftp/sw/ which are not named(5,8)
            README.  The only exceptions are  remote  hosts  from  within  the
            domain  foo.com which always get maximum throughput.  Every time(1,2,n) a
            remote client has retrieved a file(1,n) under /e/ftp/sw/ the bytes  per
            seconds  of  the matched entry line are internally multiplied by a
            factor(1,6), here 0.5.  So when the remote client retrieves its  second
            file(1,n)  it  is served with 512 bytes/s, the third time(1,2,n) with only 254
            bytes/s, the fourth time(1,2,n) with only 128 bytes/s and so on.

            The string(3,n) "oo" for the bytes per second field means no throughput
            restriction.   A  multiply factor(1,6) 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 speci-
            fied  in(1,8) the password database for the "ftp" user.  The throughput
            keyword only applies to users(1,5) who have a home directory (the argu-
            ment to the chroot(1,2)() ) of <root-dir>.


       anonymous-root <root-dir> [<class>]

            <root-dir> specifies the chroot(1,2)() 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(1,5)  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(1,8) the <root-dir>/etc/passwd(1,5) file(1,n) is
            used to determine the initial directory and the 'ftp' user's  home
            directory in(1,8) the system-wide /etc/passwd(1,5) is not used.

            For example:
                anonymous-root /home/ftp
                anonymous-root /home/localftp localnet
            causes  all  anonymous  users(1,5)  to  be  chroot(1,2)()'d to the directory
            /home/ftp then, if(3,n) the 'ftp' user exists in(1,8)  /home/ftp/etc/passwd(1,5),
            their  initial CWD is that home directory.  Anonymous users(1,5) in(1,8) the
            class  localnet,  however,  are  chroot(1,2)()'d   to   the   directory
            /home/localftp  and  their  initial  CWD  is  taken from the 'ftp'
            user's home directory in(1,8) /home/localftp/etc/passwd.


       guest-root <root-dir> [<uid-range>]

            <root-dir> specified the chroot(1,2)() 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(1,5) 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(1,8) the <root-dir>/etc/passwd(1,5) file(1,n) is used  to  determine
            the  initial directory and their home directory in(1,8) the system-wide
            /etc/passwd(1,5) 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(1,5)
                guest-root /home/staff %100-999 sally
                guest-root /home/users(1,5)/frank/ftp frank
            causes all guest users(1,5) to chroot(1,2)() to /home/users(1,5) then starts each
            user in(1,8) their home directory specified in(1,8)  /home/users(1,5)/etc/passwd.
            Users  in(1,8)  the  range  100 through 999, inclusive, and user sally,
            will be chroot(1,2)()'d to /home/staff and the CWD will be  taken  from
            their  entries  in(1,8)  /home/staff/etc/passwd.  The single user frank
            will be chroot(1,2)()'d to /home/users(1,5)/owner/ftp and the  CWD  will  be
            from his entry in(1,8) /home/users(1,5)/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(3,n) no other clause matches.


       deny-uid <uid-range> [...]

       deny-gid <gid-range> [...]

       allow-uid <uid-range> [...]

       allow-gid <gid-range> [...]

            These clauses allow specification of UID and GID values which will
            be  denied  access(2,5) to the ftp server.  The allow-uid and allow-gid
            clauses may be used to allow access(2,5) for uid/gid which would other-
            wise  be  denied.   These checks occur before all others.  Deny is
            checked before allow.  The default is to allow access.  Note  that
            in(1,8)  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(2,5) to all privileged or special users(1,5) 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(1,n)  still  exists  so  it  may  be used when changing
            /etc/ftpaccess is not desired.

            Throughout the ftpaccess file(1,n), 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(1,5) will be
            allowed access(2,5) to areas on the FTP site outside their home  direc-
            tories.   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(1,5) outside their home directories who would  oth-
            erwise be restricted.

            An  example  of the use of these clauses shows their intended use.
            Assume user 'dick' has a  home  directory  /home/dick  and  'jane'
            /home/jane:
                guest-root /home dick jane
                restricted-uid dick jane
            While both dick and jane are chroot(1,2)'d to /home, they cannot access(2,5)
            each other's files because  they  are  restricted  to  their  home
            directories.

            Whereever possible, in(1,8) situations such as this example, try not to
            rely solely upon the ftp restrictions.   As  with  all  other  ftp
            access(2,5)  rules,  try to use directory and file(1,n) permissions to back-
            stop 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(7,n,1 builtins) this limit.  If omitted, the  limit  is  20  lines.   A
            limit  of 0 (zero) implies no limit; be very careful if(3,n) 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(5,8) file(1,n) (like a  message
            file(1,n)),  admonishing  the user.  If the optional override is speci-
            fied, 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(5,8) file(1,n) (like a message file(1,n)), admonishing the
       user.  If the optional override  is  specified,  allow  the  connection
       after complaining.


       dns resolveroptions [options]

            The  resolveroptions  option  allows  you  to  tweak  name  server
            options.  The line takes  a  series  of  flags  as  documented  in(1,8)
            resolver(3,5)(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(2,8) authoritative answers) and
            turns off the dnsrch option (search the domain path).


Files
       FTPLIB/ftpaccess


See Also
       ftpd(8), umask(2), ftplog(5), ftpconversions(5), ftpshut(8)




                                                                  ftpaccess(5)

References for this manual (incoming links)