Man Linux: Main Page and Category List

NAME

       ftpaccess - ftpd configuration file

Description

       The ftpaccess file is used to configure the operation of ftpd(8).

Access Capabilities

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

            If an ANONYMOUS user is a member of any of <class>, the ftp server
            will perform a setegid() to <groupname>.  This  allows  access  to
            group-and-owner-read-only  files  and  directories to a particular
            class of anonymous  users.  <groupname>  is  a  valid  group  from
            /etc/group (or wherever mechanism your getgrent(2) library routine
            uses).

       class <class> <typelist> <addrglob> [<addrglob> ...]

            Define <class>  of  users,  with  source  addresses  of  the  form
            <addrglob>.   Multiple  members  of <class> may be defined.  There
            may be multiple "class" commands listing additional members of the
            class.   If  multiple  "class"  commands  can apply to the current
            session, the first one listed in the access file is used.  Failing
            to define a valid class for a host will cause access to be denied.
            <typelist> is a  comma-separated  list  of  any  of  the  keywords
            "anonymous",  "guest"  and  "real".   If  the  "real"  keyword  is
            included, the class can match  users  using  FTP  to  access  real
            accounts, and if the "anonymous" keyword is included the class can
            match users using anonymous  FTP.   The  "guest"  keyword  matches
            guest access accounts (see "guestgroup" for more information)

            <addrglob>  may  be  a  globbed  domain  name or a globbed numeric
            address.  It may also be the name of a file, starting with a slash
            (’/’),  which contains additional address globs, as well as in the
            form address:netmask or address/cidr.

            Placing an exclamation (!) before an <addrglob> negates the  test.
            For example:
                class rmtuser real !*.example.com
            will  classify  real  users from outside the example.com domain as
            the class rmtuser.  Use care  with  this  option.   Remember,  the
            result of each test is OR’ed with other tests on the line.

       deny <addrglob> <message_file>

            Always deny access to host(s) matching <addrglob>.  <message_file>
            is displayed.  <addrglob> may be "!nameserved" to deny  access  to
            sites  without a working nameserver.  It may also be the name of a
            file, starting with  a  slash  (’/’),  which  contains  additional
            address   globs,  as  well  as  in  the  form  address:netmask  or
            address/cidr.

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

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

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

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

            For guestgroup, if a REAL user is a member of any of  <groupname>,
            the  session  is  set  up exactly as with anonymous FTP.  In other
            words, a chroot() is done, and the user is no longer permitted  to
            issue  the  USER  and PASS commands.  <groupname> is a valid group
            from /etc/group (or whatever mechanism  your  getgrent(3)  library
            routine uses).

            The  user’s  home  directory  must  be properly set up, exactly as
            anonymous FTP would be.  The home directory field  of  the  passwd
            entry  is  divided  into  two directories.  The first field is the
            root directory which will be the argument to the  chroot(2)  call.
            The  second half is the user’s home directory relative to the root
            directory.  The two halves are separated by a "/./".

            For example, in /etc/passwd, the real entry:
                guest1:<passwd>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
            When  guest1  successfully  logs   in,   the   ftp   server   will
            chroot("/ftp")  and  then chdir("/incoming").  The guest user will
            only be able to access the directory structure under  /ftp  (which
            will  look  and act as / to guest1), just as an anonymous FTP user
            would.

            The group name may be specified by either name or numeric ID.   To
            use a numeric group ID, place a ’%’ before the number.  Ranges may
            be given.  Use an asterisk to mean all groups.

            guestuser works like guestgroup, except uses  the  user  name  (or
            numeric ID).

            realuser  and  realgroup  have  the  same  syntax, but reverse the
            effect of guestuser and guestgroup.  They allow real  user  access
            when the remote user would otherwise be determined a guest.

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

       nice <nice-delta> [<class>]

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

       defumask <umask> [<class>]

            Set the umask applied to files created by daemon if the remote use
            is a member of the named class.  If <class> is not specified, then
            use the umask as the default for classes which  do  not  have  one
            specified.

       tcpwindow <size> [<class>]

            Set the TCP window size for the data connection.  This can be used
            to control network traffic.  For instance, slow PPP  dialin  links
            may need smaller TCP windows to speed up throughput.  If you don’t
            know what this does, don’t play with it.

       keepalive <yes|no>

            Set the TCP SO_KEEPALIVE option for data  sockets.   This  can  be
            used  to control network disconnect.  Yes: set it.  No: use system
            default (usually off).  You probably want to set this.

       timeout accept <seconds>

       timeout connect <seconds>

       timeout data <seconds>

       timeout idle <seconds>

       timeout maxidle <seconds>

       timeout RFC931 <seconds>

            Set various timeouts.

            Accept (default 120 seconds): how long the daemon will wait for an
            incoming (PASV) data connection.

            Connect  (default  120  seconds):  how  long  the daemon will wait
            attempting to establish an outgoing (PORT) data connection.   This
            effects  the  actual  connetion attempt.  The daemon makes several
            attempts, sleeping a while between each, before completely  giving
            up.

            Data  (default  1200  seconds):  how long the daemon will wait for
            some activity on the data connection.  You should keep  this  long
            because  the  remote  client may have a slow link and there can be
            quite a bit of data queued for the client.

            Idle (default 900 seconds): how long the daemon will wait for  the
            next  command.   The default can also be overridden by the command
            line -a option.  This access clause overrides both.

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

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

       file-limit [<raw>] <in|out|total> <count> [<class>]

            Limit the number of data files a  user  in  the  given  class  may
            transfer.   The limit may be placed on files in, out or total.  If
            no class is specified, the limit is the default for classes  which
            do not have a limit specified.  The optional raw parameter applies
            the limit to the total traffic rather than just data files.

       data-limit [<raw>] <in|out|total> <count> [<class>]

            Limit the number of data bytes a  user  in  the  given  class  may
            transfer.   The  limit may be place on bytes in, out or total.  If
            no class is specified, the limit is the default for classes  which
            do not have a limit specified.  The optional raw parameter applies
            the limit to total traffic rather than just data files.

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

            Limit the total time a session can take.  By default, there is  no
            limit.  Real users are never limited.

       guestserver [<hostname>]

            Controls  which  hosts  may be used for anonymous or guest access.
            If used without <hostname>, denies all guest or  anonymous  access
            to  this  site.  More than one <hostname> may be specified.  Guest
            and anonymous access will only be allowed on the  named  machines.
            If  access  is  denied,  the  user  will be asked to use the first
            <hostname> listed.

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

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

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

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

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

            The optional first parameter selects whether names are  intepreted
            as  absolute or relative to the current chroot’d environment.  The
            default is to intepret names beginning with a slash as absolute.

            The  noretrieve  restrictions  may  be  placed  upon  members   of
            particular  classes.   If  any class= is specified the named files
            are only non-retrievable if the current user is a member of any of
            the given classes.

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

            Allows  retrieval  of  files  which  would  otherwise be denied by
            noretrieve.

       loginfails <number>

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

       private <yes|no>

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

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

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

Informational Capabilities

       greeting full|brief|terse

       greeting text <message>

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

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

       banner <path>

            Works  similarly to the message command, except that the banner is
            displayed before  the  user  enters  the  username/password.   The
            <path>  is  relative  to the real system root, not the base of the
            anonymous FTP directory.

            WARNING: use of this command can completely prevent  non-compliant
            FTP  clients  from  making use of the FTP server.  Not all clients
            can handle multi-line  responses  (which  is  how  the  banner  is
            displayed).

       hostname <some.host.name>

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

       email <name>

            Defines  the  email  address  of the ftp archive maintainer.  This
            string will be printed every time the %E magic cookie is used.

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

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

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

            There can be "magic cookies" in the readme file  which  cause  the
            ftp server to replace the cookie with a specified text string:
                %T      local time (form Thu Nov 15 17:12:42 1990)
                %F      free space in partition of CWD (kbytes)
                          [not supported on all systems]
                %C      current working directory
                %E      the maintainer’s email address as defined in ftpaccess
                %R      remote host name
                %L      local host name
                %u      username as determined via RFC931 authentication
                %U      username given at login time
                %M      maximum allowed number of users in this class
                %N      current number of users in this class
                %B      absolute limit on disk blocks allocated
                %b      preferred limit on disk blocks
                %Q      current block count
                %I      maximum number of allocated inodes (+1)
                %i      preferred inode limit
                %q      current number of allocated inodes
                %H      time limit for excessive disk use
                %h      time limit for excessive files

             ratios:

                %xu     Uploaded bytes
                %xd     Downloaded bytes
                %xR     Upload/Download ratio (1:n)
                %xc     Credit bytes
                %xT     Time limit (minutes)
                %xE     Elapsed time since login (minutes)
                %xL     Time left
                %xU     Upload limit
                %xD     Download limit

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

       readme <path> {<when> {<class>}}

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

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

Logging Capabilities

       log commands <typelist>

            Enables logging of individual commands by users.  <typelist> is  a
            comma-separated  list  of any of the keywords "anonymous", "guest"
            and "real".  If the "real" keyword is included,  logging  will  be
            done  for  users  using  FTP  to  access real accounts, and if the
            "anonymous" keyword is included logging will done for users  using
            anonymous  FTP.  The "guest" keyword matches guest access accounts
            (see "guestgroup" for more information).

       log transfers <typelist> <directions>

            Enables logging of file transfers for either real or anonymous FTP
            users.   Logging  of  transfers  TO  the  server (incoming) can be
            enabled separately from  transfers  FROM  the  server  (outbound).
            <typelist>  is  a  comma-separated  list  of  any  of the keywords
            "anonymous",  "guest"  and  "real".   If  the  "real"  keyword  is
            included,  logging will be done for users using FTP to access real
            accounts, and if the "anonymous" keyword is included logging  will
            done  for  users  using anonymous FTP. The "guest" keyword matches
            guest access accounts (see  "guestgroup"  for  more  information).
            <directions>  is a comma-separated list of any of the two keywords
            "inbound" and "outbound", and will respectively cause transfers to
            be logged for files sent to the server and sent from the server.

       log security <typelist>

            Enables  logging  of  violations  of  security  rules (noretrieve,
            .notar, ...)  for real, guest and/or anonymous users.   <typelist>
            is  a  comma-separated  list  of  any of the keywords "anonymous",
            "guest" and "real".  If the "real" keyword  is  included,  logging
            will  be  done for users using FTP to access real accounts, and if
            the "anonymous" keyword is included logging will  done  for  users
            using  anonymous  FTP.  The  "guest"  keyword matches guest access
            accounts (see "guestgroup" for more information).

       log syslog

       log syslog+xferlog

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

            syslog+xferlog sends the transfer log messages to both the  system
            log and the xferlog.

Upload/Download ratios

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

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

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

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

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

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

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

Miscellaneous Capabilities

       alias <string> <dir>

            Defines an alias, <string>, for a directory.  Can be used  to  add
            the concept of logical directories.

            For example:
                alias rfc: /pub/doc/rfc
            would  allow the user to access /pub/doc/rfc from any directory by
            the command "cd rfc:".  Aliases only apply to the cd command.

       cdpath <dir>

            Defines an entry in the cdpath. This defines a search path that is
            used when changing directories.

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

            If the user were to give the command:
                cd foo
            the directory will be searched for in the following order:
                ./foo
                an alias called "foo"
                /pub/packages/foo
                /.aliases/foo

            The  cd  path is only available with the cd command. If you have a
            large number of aliases you  might  want  to  set  up  an  aliases
            directory  with  links  to  all  of  the  areas  you  wish to make
            available to users.

       compress <yes|no> <classglob> [<classglob> ...]

       tar <yes|no> <classglob> [<classglob> ...]

            Enables compress or tar capabilities for any class matching any of
            <classglob>.   The  actual conversions are defined in the external
            file FTPLIB/ftpconversions.

       shutdown <path>

            If the file pointed to by <path> exists, the server will check the
            file  regularly to see if the server is going to be shut down.  If
            a shutdown is planned, the user is notified, new  connections  are
            denied   after  a  specified  time  before  shutdown  and  current
            connections are dropped  at  a  specified  time  before  shutdown.
            <path> points to a file structured as follows:
                <year> <month> <day> <hour> <minute> <deny_offset> <disc_offset>
                <text>
            where
                <year> is any year > 1970
                <month> 0-11 <---- LOOK!
                <hour> 0-23
                <minute> 0-59

            <deny_offset>  and  <disc_offset>  are  the offsets in HHMM format
            before the shutdown time that new connections will be  denied  and
            existing connections will be disconnected.

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

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

       daemonaddress <address>

            If the  value  is  not  set,  then  the  server  will  listen  for
            connections  on  every IP addresses, otherwise it will only listen
            on the IP address specified.

            Use of this clause is discouraged.  It  was  added  to  support  a
            single site’s needs.  It will completely break virtual hosting and
            the syntax is likely to change in a future version of the  daemon.

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

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

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

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

       virtual <address> <hostname|email> <string>

            Sets  the  hostname  shown  in  the  greeting  message  and STATus
            command, or the email address used in message  files  and  on  the
            HELP command, to the given <string>.

       virtual <address> allow <username> [<username> ...]

       virtual <address> deny <username> [<username> ...]

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

       virtual <address> private

            Normally,  anonymous  users  are  allowed to log in on the virtual
            server.  This option denies them access.

       virtual <address> passwd <file>

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

       virtual <address> shadow <file>

            Use a different shadow file for this virtual  domain.  The  daemon
            needs  to  be  compiled with --enable-passwd (or OTHER_PASSWD) for
            this option to work.

       defaultserver deny <username> [<username> ...]

       defaultserver allow <username> [<username> ...]

            Normally, all users  are  allowed  access  to  the  default  (non-
            virtual)  FTP server.  Use defaultserver deny to revoke access for
            specific users; specify ’*’ to deny access to all users.  Specific
            users can then be allowed using defaultserver allow.

       defaultserver private

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

            The virtual and defaultserver  allow,  deny  and  private  clauses
            provide a means to control which users are allowed access on which
            FTP servers.

       passive address <externalip> <cidr>

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

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

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

       passive ports <cidr> <min> <max>

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

            <cidr> is shorthand for an  IP  address  in  dotted-quad  notation
            followed  by  a  slash  and  the  number  of  left-most bits which
            represent the network address (as opposed to the machine address).
            For  example,  if  you’re  using  the reserved class-A network 10,
            instead of a  netmask  of  255.0.0.0  use  a  CIDR  of  /8  as  in
            10.0.0.0/8 to represent your network.

       pasv-allow <class> [<addrglob> ...]

       port-allow <class> [<addrglob> ...]

            Normally,  the  daemon does not allow a PORT command to specify an
            address different than that of the  control  connection.   And  it
            does not allow a PASV connection from another address.

            The  port-allow  clause  provides  a  list  of addresses which the
            specified class of  user  may  give  on  a  PORT  command.   These
            addresses will be allowed even if they do not match the IP-address
            of the client-side of the control connection.

            The pasv-allow clause provides  a  list  of  addresses  which  the
            specified  class  of  user  may make data connections from.  These
            addresses will be allowed even if they do not match the IP-address
            of the client-side of the control connection.

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

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

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

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

       mailserver <hostname>

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

       incmail <emailaddress>

       virtual <address> incmail <emailaddress>

       defaultserver incmail <emailaddress>

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

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

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

       mailfrom <emailaddress>

       virtual <address> mailfrom <emailaddress>

       defaultserver mailfrom <emailaddress>

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

Permission Capabilities

       chmod <yes|no> <typelist>

       delete <yes|no> <typelist>

       overwrite <yes|no> <typelist>

       rename <yes|no> <typelist>

       umask <yes|no> <typelist>

            Allows or disallows the ability to perform the specified function.
            By default, all users are allowed.

            <typelist> is a  comma-separated  list  of  any  of  the  keywords
            "anonymous", "guest", "real" and "class=".  When "class=" appears,
            it must be followed by a classname.  If any  class=  appears,  the
            <typelist> restriction applies only to users in that class.

       passwd-check <none|trivial|rfc822> (<enforce|warn>)

            Define  the level and enforcement of password checking done by the
            server for anonymous ftp.
                none      no password checking performed.
                trivial   password must contain an ’@’.
                rfc822    password must be an rfc822 compliant address.

                warn      warn the user, but allow them to log in.
                enforce   warn the user, and then log them out.

       deny-email <case-insensitive-email-address>

            Consider the e-mail address given as an argument  as  invalid.  If
            passwd-check  is  set  to  enforce,  anonymous  users  giving this
            address as password cannot log in.  That way, you can  stop  users
            from  having stupid WWW browsers use fake addresses like IE?0User@
            or mozilla@. (by using this, you are not shutting out users  using
            a WWW browser for ftp - you just make them configure their browser
            correctly.) Only one address per line, but you can  have  as  many
            deny-email addresses as you like.

       path-filter  <typelist>  <mesg>  <allowed_charset> {<disallowed regexp>
       ...}

            For  users  in <typelist>, path-filter defines regular expressions
            that control what a filename can or can  not  be.   There  may  be
            multiple  disallowed  regexps.   If  a  filename is invalid due to
            failure to match the regexp criteria, <mesg> will be displayed  to
            the user.  For example:
                path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9._]*$ ^\. ^-
            specifies  that  all  upload filenames for anonymous users must be
            made of only the characters A-Z, a-z, 0-9, and "._-" and  may  not
            begin  with  a  "."   or  a  "-".   If  the  filename  is invalid,
            /etc/pathmsg will be displayed to the user.

       upload  [absolute|relative]   [class=<classname>]...   [-]   <root-dir>
       <dirglob> <yes|no> <owner> <group> <mode> ["dirs"|"nodirs"] [<d_mode>]

            Define a directory with <dirglob> that permits or denies  uploads.

            If  it  does permit uploads, all newly created files will be owned
            by <owner>  and  <group>  and  will  have  their  permissions  set
            according  to  <mode>,  existing  files which are overwritten will
            keep their original ownership and permissions.

            Directories are matched on a best-match basis.

            For example:
                upload /var/ftp *              no
                upload /var/ftp /incoming      yes ftp daemon 0666
                upload /var/ftp /incoming/gifs yes jlc guest  0600 nodirs
            would only allow uploads into /incoming and /incoming/gifs.  Files
            that  were  uploaded to /incoming would be owned by ftp/daemon and
            would have permissions of 0666.  File uploaded  to  /incoming/gifs
            would  be  owned  by  jlc/guest and have permissions of 0600. Note
            that the <root-dir> here must match the home  directory  specified
            in the password database for the "ftp" user.

            The  optional  "dirs"  and  "nodirs"  keywords can be specified to
            allow or disallow the creation of  new  subdirectories  using  the
            mkdir command.

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

            If directories are permitted, the optional <d_mode> determines the
            permissions  for  a  newly  created  directory.   If  <d_mode>  is
            omitted, the permissions are inferred from <mode> or are  0777  if
            <mode> is also omitted.

            The upload keyword only applies to users who have a home directory
            (the argument to the chroot() ) of <root-dir>.  <root-dir> may  be
            specified as "*" to match any home directory.

            The  <owner> and/or <group> may each be specified as "*", in which
            case any uploaded files or directories will be  created  with  the
            ownership of the directory in which they are created.

            The  optional first parameter selects whether <root-dir> names are
            intepreted  as  absolute  or  relative  to  the  current  chroot’d
            environment.   The  default  is  to  intepret  <root-dir> names as
            absolute.

            You can specify any number  of  ’class=<classname>’  restrictions.
            If  any are specified, this upload clause only takes effect if the
            current user is a member of one of the classes.

            Please  read  the  upload.configuration.HOWTO   for   a   complete
            discussion  of  how  to  configure  your server to allow uploading
            files.

       throughput <root-dir> <subdir-glob> <file-glob-list> <bytes-per-second>
       <bytes-per-second-multiply> <remote-glob-list>

            Define  files  via  comma-seperated  <file-glob-list>  in   subdir
            matched  by  <subdir-glob>  under  <root-dir> that have restricted
            transfer throughput of <bytes-per-second>  on  download  when  the
            remote  hostname  or remote IP address matches the comma-seperated
            <remote-glob-list>.

            Entries are matched on a best-match basis.

            For example:
                throughput /e/ftp *    *      oo   -   *
                throughput /e/ftp /sw* *      1024 0.5 *
                throughput /e/ftp /sw* README oo   -   *
                throughput /e/ftp /sw* *      oo   -   *.foo.com
            would set maximum throughput per default, but restrict download to
            1024  bytes/s  for  any files under /e/ftp/sw/ which are not named
            README.  The only exceptions are  remote  hosts  from  within  the
            domain  foo.com which always get maximum throughput.  Every time a
            remote client has retrieved a file under /e/ftp/sw/ the bytes  per
            seconds  of  the matched entry line are internally multiplied by a
            factor, here 0.5.  So when the remote client retrieves its  second
            file  it  is served with 512 bytes/s, the third time with only 254
            bytes/s, the fourth time with only 128 bytes/s and so on.

            The string "oo" for the bytes per second field means no throughput
            restriction.   A  multiply factor of 1.0 or "-" means no change of
            the throughput after every successful transfer.

            Note that the  <root-dir>  here  must  match  the  home  directory
            specified  in  the  password  database  for  the  "ftp" user.  The
            throughput keyword only applies to users who have a home directory
            (the argument to the chroot() ) of <root-dir>.

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

            <root-dir> specifies the chroot() path for anonymous users.  If no
            anonymous-root is matched, the old  method  of  parsing  the  home
            directory for the ’ftp’ user is used.  If no <class> is specified,
            this is the root directory for anonymous  users  who  do  not  any
            other anonymous-root specification.  Multiple classes may be given
            on the line.  If an anonymous-root is chosen  for  the  user,  the
            ’ftp’  user’s  home directory in the <root-dir>/etc/passwd file is
            used to determine the initial directory and the ’ftp’ user’s  home
            directory in the system-wide /etc/passwd is not used.

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

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

            <root-dir> specified the chroot() path for  guest  users.   If  no
            guest-root  is  is  matched,  the old method of parsing the user’s
            home directory is used.  If no <uid-range> is specified,  this  is
            the  root  directory  for  guest  users who do not match any other
            guest-root specification.  Multiple uid ranges may be given on the
            line.   If  a  guest-root  is chosen for the user, the user’s home
            directory in the <root-dir>/etc/passwd file is used  to  determine
            the  initial directory and their home directory in the system-wide
            /etc/passwd is not used.

            <uid-range> specifies numeric UID values.  Ranges are specified by
            giving  the  lower  and  upper  bounds (inclusive), separated by a
            dash.  Omitting the lower bound means "all up to", and omitted the
            upper bound means "all starting from".

            For example:
                guest-root /home/users
                guest-root /home/staff %100-999 sally
                guest-root /home/users/frank/ftp frank
            causes all guest users to chroot() to /home/users then starts each
            user in their home directory specified in  /home/users/etc/passwd.
            Users  in  the  range  100 through 999, inclusive, and user sally,
            will be chroot()’d to /home/staff and the CWD will be  taken  from
            their  entries  in  /home/staff/etc/passwd.  The single user frank
            will be chroot()’d to /home/users/owner/ftp and the  CWD  will  be
            from his entry in /home/users/owner/ftp/etc/passwd.

            Note  that  order  is important for both anonymous-root and guest-
            root.  If a user would match  multiple  clauses,  only  the  first
            applies;  with the exception of the clause which has no <class> or
            <uid-range>, which applies only if no other clause matches.

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

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

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

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

            These clauses allow specification of UID and GID values which will
            be  denied  access to the ftp server.  The allow-uid and allow-gid
            clauses may be used  to  allow  access  for  uid/gid  which  would
            otherwise  be denied.  These checks occur before all others.  Deny
            is checked before allow.  The default is to  allow  access.   Note
            that  in most cases, this can remove the need for an /etc/ftpusers
            files.  For example:
                deny-gid %-99 %65535
                deny-uid %-99 %65535
                allow-gid ftp
                allow-uid ftp
            denies ftp access to all privileged or special users and groups on
            a Linux box except the anonymous ’ftp’ user/group.  In many cases,
            this can eliminate the need for the /etc/ftpusers  file.   Support
            for  that  file  still  exists  so  it  may  be used when changing
            /etc/ftpaccess is not desired.

            Throughout the ftpaccess file, any place a single UID  or  GID  is
            allowed, either names or numbers may be used.  To use numbers, put
            a ’%’ before it.  In places where a range is allowed, put the  ’%’
            before the range.

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

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

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

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

            These  clauses  control whether or not real or guest users will be
            allowed access to  areas  on  the  FTP  site  outside  their  home
            directories.   They are not meant to replace the use of guestgroup
            and guestuser.  Instead, use these to supplement the operation  of
            guests.   The unrestricted-uid and unrestricted-gid clauses may be
            used to allow users  outside  their  home  directories  who  would
            otherwise be restricted.

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

            Whereever possible, in situations such as this example, try not to
            rely solely upon the ftp restrictions.   As  with  all  other  ftp
            access  rules,  try  to  use  directory  and  file  permissions to
            backstop the operation of the ftpaccess configuration.

       site-exec-max-lines <number> [<class> ...]

            The SITE EXEC feature traditionally limits the number of lines  of
            output which may be sent to the remote client.  This clause allows
            you to set this limit.  If omitted, the  limit  is  20  lines.   A
            limit  of 0 (zero) implies no limit; be very careful if you choose
            to remove the limit.  If a clause is  found  matching  the  remote
            user’s  class,  that  limit  is  used.  Otherwise, the clause with
            class ’*’, or no class given, is used.  For example:
                site-exec-max-lines 200 remote
                site-exec-max-lines 0 local
                site-exec-max-lines 25
            limits output from SITE EXEC (and therefore  SITE  INDEX)  to  200
            lines  for  ´remote’ users, specifies there is no limit at all for
            ’local’ users, and sets a limit of 25 lines for all other users.

       dns refuse_mismatch <filename> [override]

            Refuse FTP sessions when the forward and reverse lookups  for  the
            remote  site do not match.  Display the named file (like a message
            file),  admonishing  the  user.   If  the  optional  override   is
            specified, allow the connection after complaining.

       dns refuse_no_reverse <filename> [override]

        Refuse  FTP sessions when there is no reverse DNS entry for the remote
        site.  Display the named file (like a message file),  admonishing  the
        user.   If  the  optional  override is specified, allow the connection
        after complaining.

       dns resolveroptions [options]

            The  resolveroptions  option  allows  you  to  tweak  name  server
            options.   The  line  takes  a  series  of  flags as documented in
            resolver(3) (with the leading RES_ removed).  Each can be preceded
            by an optional + or -.  For example,
                dns resolveroptions +aaonly -dnsrch
            turns on the aaonly option (only accept authoritative answers) and
            turns off the dnsrch option (search the domain path).

Files

       FTPLIB/ftpaccess

See Also

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

                                                                  ftpaccess(5)