Description

Normally, a 530 response message is sent to an FTP client immediately after a failed authentication attempt, with a standard message indicating the the reason of failure. In the case of a wrong password, the reason is usually "Login incorrect." This message can be customized with the AccessDenyMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login.

See also

Examples

AccessDenyMsg "Guest access denied for %u."

Description

Normally, a 230 response message is sent to an FTP client immediately after authentication, with a standard message indicating that the user has either logged in or that anonymous access has been granted. This message can be customized with the AccessGrantMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login.

See also

Examples

AccessGrantMsg "Guest access granted for %u."

Description

The Allow directive is used inside a <Limit> context to explicitly specify which hosts and/or networks have access to the commands or operations being limited. Allow is typically used in conjunction with Order and Deny in order to create sophisticated (or perhaps not-so-sophisticated) access control rules. Allow takes an optional first argument; the keyword from. Using from is purely cosmetic. The remaining arguments are expected to be a list of hosts and networks which will be explicitly granted access. The magic keyword all can be used to indicate that all hosts will explicitly be granted access (analogous to the AllowAll directive, except with a lower priority). Additionally, the magic keyword none can be used to indicate that no hosts or networks will be explicitly granted access (although this does not prevent them from implicitly being granted access). If all or none is used, no other hosts or networks can be supplied. Host and network addresses can be specified by name or numeric address. For security reasons, it is recommended that all address information be supplied numerically. Relying solely on named addresses causes security to depend a great deal upon DNS servers which may themselves be vulnerable to attack or spoofing. Numeric addresses which specify an entire network should end in a trailing period (i.e. 10.0.0. for the entire 10.0.0 subnet). Named addresses which specify an entire network should begin with a leading period (i.e. .proftpd.net for the entire proftpd.net domain).

See also

Allow Order Limit

Examples

<Limit LOGIN>
Order allow,deny
Allow from 128.44.26.,128.44.26.,myhost.mydomain.edu,.trusted-domain.org
Deny from all
</Limit>

Description

The AllowAll directive explicitly allows access to a <Directory>, <Anonymous> or <Limit> block. Although proftpd's default behavior is to allow access to a particular object, the default is an implicit allow. AllowAll creates an explicit allow, overriding any higher level denial directives.

See also

DenyAll

Examples

Description

AllowClass specifies a class-expression that is specifically permitted access within the context of the <Limit> block it is applied to. class-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of classes or "not" classes (by prefixing a class name name with the `!' character) that are to be allowed access to the block.

By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit allow to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.

See also

AllowUser DenyUser AllowGroup DenyGroup DenyClass

Examples

  # A regular expression AllowClass directive
  AllowClass regex ^known

  # An AND-evaluated ClassUser directive
  DenyClass AND bad,scanner

Description

AllowFilter allows the configuration of a regular expression that must be matched for all command arguments sent to ProFTPD. It is extremely useful in controlling what characters may be sent in a command to ProFTPD, preventing some possible types of attacks against ProFTPD. The regular expression is applied against the arguments to the command sent by the client, so care must be taken when creating a proper regex. Commands that fail the regex match result in a "Forbidden command" error being returned to the client. If the regular-expression argument contains whitespace, it must be enclosed in quotes.

See also

DenyFilter

Examples

# Only allow commands containing alphanumeric characters and whitespace
AllowFilter "^[a-zA-Z0-9 ,]*$"

Description

Normally, proftpd disallows clients from using the ftp PORT command with anything other than their own address (the source address of the ftp control connection), as well as preventing the use of PORT to specify a low-numbered (< 1024) port. In either case, the client is sent an "Invalid port" error and a message is syslog'd indicating either "address mismatch" or "bounce attack". By enabling this directive, proftpd will allow clients to transmit foreign data connection addresses that do not match the client's address. This allows such tricks as permitting a client to transfer a file between two FTP servers without involving itself in the actual data connection. Generally it's considered a bad idea, security-wise, to permit this sort of thing. AllowForeignAddress only affects data connection addresses; not tcp ports. There is no way (and no valid reason) to allow a client to use a low-numbered port in its PORT command.

See also

Examples

Description

AllowGroup specifies a group-expression that is specifically permitted within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be allowed access to the block.

By default, the expression is parsed as a boolean "AND" list, meaning that ALL elements of the expression must evaluate to logically true in order to the explicit allow to apply. In order to treat the expression as a boolean "OR" list, meaning that ANY of the elements must evaluate to logically true, use the optional "OR" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.

See also

DenyGroup, DenyUser, AllowUser

Examples

  # An OR-evaluated AllowGroup directive
  AllowGroup OR www,doc

  # A regular expression DenyGroup directive
  DenyGroup regex ^sys

Description

By default, the server will the path of any configured SystemLog, any configured TransferLogs, and any configured ExtendedLogs to see if they are symbolic links. If the paths are symbolic links, the server will refuse to log to that link unless explicitly configured to do so via this directive.

See also

Examples

AllowLogSymlinks on

Description

Normally, the server will look for and parse any files in the encountered directories called ".ftpaccess". The files provide a functionality similar to Apache's .htaccess files -- mini-configuration files. This directive controls when those .ftpaccess files will be parsed.

The optional parameters are used to restrict the use of .ftpaccess files only to specific users. If the "user" restriction is given, then expression is a user-expression specifying to which users the rule applies. Similarly for the "group" restriction. For the "class" restriction, the expression is simply the name of connection class for whom the rule will apply.

See also

Description

The AllowOverwrite directive permits newly transfered files to overwrite existing files. By default, ftp clients cannot overwrite existing files.

See also

Examples

Description

The AllowRetrieveRestart directive permits or denies clients from performing "restart" retrieve file transfers via the FTP REST command. By default this is enabled, so that clients may resume interrupted file transfers at a later time without losing previously collected data.

See also

AllowStoreRestart

Examples

Description

The AllowStoreRestart directive permits or denies clients from "restarting" interrupted store file transfers (those sent from client to server). By default restarting (via the REST command) is not permitted when sending files to the server. Care should be taken to disallow anonymous ftp "incoming" transfers to be restarted, as this will allow clients to corrupt or increase the size of previously stored files (even if not their own).

The REST (Restart STOR) command is automatically blocked when HiddenStores is enabled, with the server returning a 501 error code to the client.

See also

AllowRetrieveRestart DeleteAbortedStores HiddenStores

Examples

Description

AllowUser specifies a user-expression that is specifically permitted access within the context of the <Limit> block it is applied to. user-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of users or "not" users (by prefixing a user name with the `!' character) that are to be allowed access to the block.

By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit allow to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.

See also

DenyUser AllowGroup DenyGroup

Examples

  # A regular expression AllowUser directive
  AllowUser regex ^ftp

  # An AND-evaluated DenyUser directive
  DenyUser AND system,test

Description

The AnonRatio directive ....

See also

AnonRatio

Examples

Description

The AnonRejectPasswords directive configures a regular expression filter for passwords given for anonymous logins. If the given anonymous password matches the configured regular expression, the anonymous login is denied.

See also

AnonRequirePassword

Examples

  # Reject all <Anonymous> logins that use "evil.org" as part of the password
  AnonRejectPasswords @evil\.org$

Description

Normally, anonymous FTP logins do not require the client to authenticate themselves via the normal method of a transmitted cleartext password which is hashed and matched against an existing system user's password. Instead, anonymous logins are expected to enter their e-mail address when prompted for a password. Enabling the AnonRequirePassword directive requires anonymous logins to enter a valid password which must match the password of the user that the anonymous daemon runs as. However using AuthUsingAlias authentication can be matched against the password of the login username. This can be used to create "guest" accounts, which function exactly as normal anonymous logins do (and thus present a "chrooted" protected file system to the client), but require a valid password on the server's host system.

See also

AnonymousGroup AuthAliasOnly AuthUsingAlias

Description

The Anonymous configuration block is used to create an anonymous FTP login, and is terminated by a matching </Anonymous> directive. The root-directory parameters specifies which directory the daemon will first chdir to, and then chroot, immediately after login. Once the chroot operation successfully completes, higher level directories are no longer accessible to the running child daemon (and thus the logged in user). By default, proftpd assumes an anonymous login if the remote client attempts to login as the currently running user; unless the current user is root, in which case anonymous logins are not allowed regardless of the presence of an <Anonymous> block. To force anonymous logins to be bound to a user other than the current user, see the User and Group directives. In addition, if a User or Group directive is present in an <Anonymous> block, the daemon permanently switches to the specified uid/gid before chroot()ing. Normally, anonymous logins are not required to authenticate with a password, but are expected to enter a valid e-mail address in place of a normal password (which is logged). If this behavior is undesirable for a given <Anonymous> configuration block, it can be overridden via the AnonRequirePassword directive.

Note: Chroot()ed anonymous directories do not need to have supplemental system files in them, nor do they need to have any sort of specific directory structure. This is because proftpd is designed to acquire as much system information as possible before the chroot, and to leave open those files which are needed for normal operation and reside outside the new root directory.

See also

Examples

Example of a typical anonymous FTP configuration:

<Anonymous /home/ftp>
  # After anonymous login, daemon runs as user/group ftp.
  User ftp
  Group ftp

  # The client login 'anonymous' is aliased to the "real" user 'ftp'.
  UserAlias anonymous ftp

  # Deny write operations to all directories, except for 'incoming' where 
  # 'STOR' is allowed (but 'READ' operations are prohibited)

  <Directory *>
    <Limit WRITE>
      DenyAll
    </Limit>
  </Directory>

  <Directory incoming>
    <Limit READ >
      DenyAll
    </Limit>
    <Limit STOR>
      AllowAll
    </Limit>
  </Directory>

</Anonymous>

Description

The AnonymousGroup directive specifies a group-expression to which all matching users will be considered anonymous logins. The group-expression argument is a boolean logically ANDed list of groups to which the user must be a member of (or non-member if the group name is prefixed with a `!' character). For more information on group-expressions see the DefaultRoot directive. If the authenticating user is matched by an AnonymousGroup directive, no valid password is required, and a special dynamic anonymous configuration is created, with the user's home directory as the default root directory. If a DefaultRoot directive also applies to the user, this directory is used instead of the user's home dir. Great care should be taken when using AnonymousGroup, as improper configuration can open up user home directories to full read/write access to the entire world.

See also

AuthAliasOnly AuthUsingAlias AnonRequirePassword DefaultRoot

Examples

Description

AuthAliasOnly restricts authentication to "aliased" logins only; i.e. those usernames provided by clients which are "mapped" to a real userid by the UserAlias directive. Turning AuthAliasOnly `on' in a particular context will cause proftpd to completely ignore all non-aliased logins for the entire context. If no contexts are available without AuthAliasOnly set to `on', proftpd rejects the client login and sends an appropriate message to syslog.

See also

AnonymousGroup AuthUsingAlias AnonRequirePassword UserAlias

Examples

Description

AuthGroupFile specifies an alternate groups file, having the same format as the system /etc/group file, and if specified is used during authentication and group lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthGroupFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthUserFile).

Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.

See also

AuthUserFile

Examples

Description

The AuthOrder directive configures the names of auth modules, and the order in which they will be checked when authenticating a user.

At least one module name must be given; there is no maximum number of modules that can be listed. The listed module names must the full name of the source file, e.g. "mod_auth_unix.c". To see a full list of module names, use "proftpd -l". Do not use "mod_auth.c", as that module is the authentication front end module, and is necessary.

You can make an auth module be "authoritative" by appending an asterisk (*) after the module name. Usually this is done for the "mod_auth_pam.c" module, to ensure that the login fails if the PAM check fails.

Examples

  # Use only AuthUserFiles when authenticating, and not the system's /etc/passwd
  AuthOrder mod_auth_file.c

  # If the user's information is not in LDAP, they're not a user to use
  # this server.
  AuthOrder mod_ldap.c

  # Use SQL tables first, then LDAP, for authentication
  AuthOrder mod_sql.c mod_ldap.c

  # Use the normal system /etc/passwd and PAM, but make sure that PAM is
  # authoritative about accepting or rejecting the login
  AuthOrder mod_auth_pam.c* mod_auth_unix.c

Description

This directive determines whether PAM is used as an authentication method by ProFTPD. Enabled by default to fit in with the design policy of using PAM as the primary authentication mechanism.

See also

Examples

Description

This directive allows you to specify the PAM service name used in authentication. PAM allows you to specify a service name to use when authenticating. This allows you to configure different PAM service names to be used for different virtual hosts. The directive was renamed from PAMConfig post 1.2.0 pre10.

See also

Examples

# Virtual host foobar authenticates differently than the rest

AuthPAMConfig foobar

# This assumes, that you have a PAM service named foobar
# configured in your /etc/pam.conf file or /etc/pam.d directory. 

Description

AuthUserFile specifies an alternate passwd file, having the same format as the system /etc/passwd file, and if specified is used during authentication and user lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthUserFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthGroupFile).

Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.

See also

AuthGroupFile

Examples

Description

AuthUsingAlias disables the resolving of mapped usernames for authentication purposes. For example, if you have mapped the username anonymous to the "real" user ftp, the password gets checked against the user "anonymous". When AuthUsingAlias is disabled, the checked username would be "ftp".

See also

AnonymousGroup AuthAliasOnly AnonRequirePassword

Examples

An example of an Anonymous configuration using
AuthUsingAlias
# Basic Read-Only Anonymous Configuration.
<Anonymous /home/ftp>
UserAlias             anonymous  nobody
UserAlias             ftp        nobody
AuthAliasOnly         on
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>
# Give Full Read-Write Anonymous Access to certain users
<Anonymous /home/ftp>
AnonRequirePassword   on
AuthAliasOnly         on
AuthUsingAlias        on
# The list of authorized users.
# user/pass lookup is for each user, not password entry
# of server uid ('nobody' in this example).
UserAlias             fred       nobody
UserAlias             joe        nobody
<Limit ALL>
AllowAll
</Limit>
</Anonymous>

Description

Cause of too much confusion this directive has been deprecated with ProFTPD 1.3.0rc1. Please take a look at the VirtualHost and DefaultAddress directive. The Bind directive allows additional IP addresses to be bound to a main or VirtualHost configuration. Multiple Bind directives can be used to bind multiple addresses. The address argument should be either a fully qualified domain name or a numeric dotted-quad IP address. Incoming connections destined to an additional address added by Bind are serviced by the context containing the directive. Additionally, if SocketBindTight is set to on, a specific listen connection is created for each additional address.

See also

VirtualHost DefaultAddress

Examples

Description

The ByteRatioErrMsg directive .... Example: ByteRatioErrMsg

See also

Examples

Description

The CapabilitiesEngine directive enables or disables the module's runtime capabilities engine. If set to off, this module does no runtime capabilities processing at all. Use this directive to disable the module.

Description

By default, mod_cap removes all but two capabilities from the session-handling process: CAP_NET_BIND_SERVICE, for binding to ports lower than 1024 (required for active data transfers), and CAP_CHOWN, for allowing a process to change a file's ownership to a different user. The latter capability is only strictly necessary if the UserOwner configuration directive is in use; if not being used, the CAP_CHOWN capability is best removed. The CapabilitiesSet directive is used to manipulate the set of capabilities that mod_cap grants.

To remove a capability, prefix the name with a '-'; to enable a capability, use '+'. At present, this directive only supports one capability: CAP_CHOWN.

Example

<IfModule mod_cap.c> CapabilitiesEngine on CapabilitiesSet -CAP_CHOWN </IfModule>

Description

Adds an entry to a search path that is used when changing directories. For example: CDPath /home/public CDPath /var/devel This allows a user to cd into any directory directly under /home/public or /var/devel, provided they have the appropriate rights. So, if /home/public/proftpd exists, cd proftpd will bring the user to that directory, regardless of where they currently are in the directory tree.

See also

Examples

Description

When configuring proftpd, it is sometimes nice, or even necessary, to tag or label a client as belonging to some group, based on that client's IP address or DNS hostname. A "class" is the name for such connection-based groupings in ProFTPD terms. A class is defined to have a name, and as having certain criteria such as IP addresses, IP subnets/masks, and DNS hostnames. A client that connects to the daemon that has matching characteristics is then labeled as belonging to that class.

Within a <Class> section, the From directive is used to list the IP addresses, IP subnet/masks, and DNS names that make up the class.

See also

From

Examples

   From 192.168.0.0/16

This defines a class named "internal"; any client connecting from 192.168.0.0/16 will belong to this class. And if you wanted to define a class for all clients not connecting from 192.168.0.0/16 address space:

   From !192.168.0.0/16

A more complicated class might include matching DNS names as well:

   From 1.2.3.4 From proxy.*.com From my.example.com From 5.6.7.8

Description

The CommandBufferSize directive controls the maximum command length permitted to be sent to the server. This allows you to effectively control what the longest command the server may accept it, and can help protect the server from various Denial of Service or resource-consumption attacks.

See also

Examples

Description

The CreateHome directive configures the server to automatically create a user's home directory, if that directory does not exist, during the login process.

The mode parameter is used to configure the absolute mode of the home directory created. If not specified, the module will default to 700.

The optional skel path parameter can be used to configure an /etc/skel-like directory containing account initialization files and directories. The parameter must be the full path to the directory. The directory must not be world-writeable. Files copied from this directory into the new home directory will have the UID and GID of the logging-in user. Note that sockets and FIFOs in the skeleton directory will not be copied; any setuid or setgid bits on files will be removed from the copied files in the target home directory.

The optional dirmode, uid, and gid parameters can be used to specify the mode, owner, and group for intermediate directories that may need to be created in order to create the target home directory. By default, the mode for such intermediate directories will be 711. NOTE: using a mode that does not allow for the execute bit to be enabled can cause havoc. You have been warned.

Examples

# Use the CreateHome default settings CreateHome on

# Specify a skeleton directory CreateHome on skel /etc/ftpd/skel

# No skeleton, but make sure that intermediate directories have 755 # permissions. CreateHome on dirmode 755

# Skeleton directory, with 700 intermediate directories CreateHome on skel /etc/ftpd/skel dirmode 700

Description

The CwdRatioMsg directive .... Example: CwdRatioMsg

See also

Examples

Description

The DebugLevel directive configures the debugging level the server will use when logging. The level parameter must be between 0 (lowest) and 10 (highest). This configuration directive will take precedence over any command-line debugging options used.

Description

This directive sets the the address the main server instance will bind to, the default behaviour is to select whatever IP the system reports as being the primary IP.

Starting with ProFTPD 1.3.0rc1 it's possible to use more than one FQDN or IP Address. With this change the old Bind directive has been deprecated.

See also

VirtualHost

Examples

ServerName "Default FTP Server"
Port 21

# We want the main server instance to listen on a specific IP
DefaultAddress 192.168.10.30

## Since 1.3.0rc1 it's also possible to use the following:
# DefaultAddress 192.168.10.30 my.domain.tld

Description

Determines the directory a user is placed in after logging in. By default, the user is put in their home directory. The specified directory can be relative to the user's home directory. NOTE: If the specified directory is not available then DefaultChdir is treated as if it wasn't there in the first place. In particular, in this case the directory a user is placed in after logging in is determined by the other settings in proftpd.conf.

See also

DefaultRoot

Examples

Description

The DefaultRoot directive controls the default root directory assigned to a user upon login. If DefaultRoot is set to a directory other than "/", a chroot operation is performed immediately after a client authenticates. This can be used to effectively isolate the client from a portion of the host system filespace. The specified root directory must begin with a / or can be the magic character '~'; meaning that the client is chroot jailed into their home directory.

When the specified chroot directory is a symlink this will be resolved to it's parent first before setting up the chroot. This can have unwanted side effects. For example if a user has write access to the symlink he could modify it so that it points to '/'. Thus the chroot would be the root directory of the server, resulting in insufficient or no restrictions.

If the DefaultRoot directive specifies a directory which disallows access to the logged-in user's home directory, the user's current working directory after login is set to the DefaultRoot instead of their normal home directory. DefaultRoot cannot be used in <Anonymous> configuration blocks, as the <Anonymous> directive explicitly contains a root directory used for Anonymous logins. The special character '~' is replaced with the authenticating user's home directory immediately after login. Note that the default root may be a subdirectory of the home directory, such as "~/anon-ftp".

The optional group-expression argument can be used to restrict the DefaultRoot directive to a unix group, groups or subset of groups. The expression takes the format: [!]group-name1[,[!]group-name2[,...]]. The expression is parsed in a logical boolean AND fashion, such that each member of the expression must evaluate to logically TRUE in order for the DefaultRoot directive to apply. The special character '!' is used to negate group membership.

Care should be taken when using DefaultRoot. Chroot "jails" should not be used as methods for implementing general system security as there are potentially ways that a user can "escape" the jail.

See also

Examples

Example of a DefaultRoot configuration:

ServerName "A test ProFTPD Server"
ServerType inetd
User ftp
Group ftp
#
# This causes proftpd to perform a chroot into the authenticating user's directory 
# immediately after login.
# Once this happens, the user is unable to "see" higher level directories.
# Because a group-expression is included, only users who are a member of
# the group 'users' and NOT a member of 'staff' will have their default
# root directory set to '~'.
DefaultRoot ~ users,!staff
... 

Description

The DefaultServer directive controls which server configuration is used as the default when an incoming connection is destined for an IP address which is neither the host's primary IP address or one of the addresses specified in a <VirtualHost> configuration block. Normally such "unknown" connections are issued a "no server available to service your request" message and disconnected. When DefaultServer is turned on for either the primary server configuration or a virtual server, all unknown destination connections are serviced by the default server. Only a single server configuration can be set to default.

See also

Examples

Description

DefaultTransferMode sets the default transfer mode of the server. By default, carriage-return/linefeed translation will be performed (ASCII mode).

See also

Examples

Description

The DeferWelcome directive configures a master or virtual server to delay transmitting the ServerName and address to new connections, until a client has successfully authenticated. If enabled, the initial welcome message will be exceedingly generic and will not give away any type of information about the host that the daemon is actively running on. This can be used by security-conscious administrators to limit the amount of "probing" possible from non-trusted networks/hosts.

See also

ServerIdent ServerName

Examples

Description

This directive is used to initialise defines for use in conjunction with the IfDefine directive

See also

IfDefine, IfModule

Examples

IfDefine LoadLimiting
IfDefine HighPerformanceSetup

Description

The DelayEngine directive enables or disables the module's runtime delaying calculations. If it is set to off this module does no delaying. Use this directive to disable the module.

See also

DelayTable

Examples

  <IfModule mod_delay.c>
    DelayEngine off
  </IfModule>

Description

The DelayTable directive configures a path to a file that mod_delay uses for storing its timing data. The given path must be an absolute path. It is recommended that this file not be on an NFS mounted partition.

Note that timing data is kept across daemon stop/starts. When new <VirtualHost>s are added to the configuration, though, mod_delay will detect that it does not have a suitable DelayTable for the new configuration, and will clear all stored data.

See also

DelayEngine

Examples

Description

The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded HiddenStores files if the transfer is stopped via the ABOR command rather than a connection failure.

See also

HiddenStores

Examples

Description

The Deny directive is used to create a list of hosts and/or networks which will explicitly be denied access to a given <Limit> context block. The magic keywords "ALL" and "NONE" can be used to indicate that all hosts are denied access, or that no hosts are explicitly denied (respectively). For more information on the syntax and usage of Deny see: Allow and Order.

See also

Allow Order Limit

Examples

Description

The DenyAll directive is analogous to a combination of "order deny,allow <cr> deny from all", with the exception that it has a higher precedence when parsed. It is provided as a convenient method of completely denying access to a directory, anonymous ftp or limit block. Because of its precedence, it should not be intermixed with normal Order/Deny directives. The DenyAll directive can be overridden at a lower level directory by using AllowAll. DenyAll and AllowAll are mutually exclusive.

See also

AllowAll

Examples

Description

DenyClass specifies a class-expression that is specifically denied access within the context of the <Limit> block it is applied to. class-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of classes or "not" classes (by prefixing a class name name with the `!' character) that are to be denied access to the block.

By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit deny to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.

See also

AllowUser DenyUser AllowGroup DenyGroup AllowClass

Examples

  # A regular expression AllowClass directive
  AllowClass regex ^known

  # An AND-evaluated ClassUser directive
  DenyClass AND bad,scanner

Description

Similar to AllowFilter, DenyFilter specifies a regular expression which must not match any of the command arguments. If the regex does match, a "Forbidden command" error is returned to the client. This can be especially useful for forbidding certain command argument combinations from ever reaching ProFTPD.

Notes: The 'PASV' command cannot be blocked using this directive.

See also

AllowFilter

Examples

# We don't want to allow any commands with % being sent to the server
DenyFilter "%"

Description

DenyGroup specifies a group-expression that is specifically denied within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be denied access to the block.

By default, the expression is parsed as a boolean "AND" list, meaning that ALL elements of the expression must evaluate to logically true in order to the explicit deny to apply. In order to treat the expression as a boolean "OR" list, meaning that ANY of the elements must evaluate to logically true, use the optional "OR" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.

See also

DenyUser, AllowUser AllowGroup

Examples

  # An OR-evaluated AllowGroup directive
  AllowGroup OR www,doc

  # A regular expression DenyGroup directive
  DenyGroup regex ^sys

Description

DenyUser specifies a user-expression that is specifically denied within the context of the <Limit> block it is applied to. user-expression is a comma delimited list of users or "not" users (by prefixing a user name with the `!' character).

By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit deny to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.

See also

DenyGroup, AllowUser AllowGroup

Examples

  # A regular expression AllowUser directive
  AllowUser regex ^ftp

  # An AND-evaluated DenyUser directive
  DenyUser AND system,test

Description

This directive creates a block of configuration directives which applies only to the specified directory and its sub-directories. The block is ended with </Directory>. Per-directory configuration is enabled during run-time with a "closest" match algorithm, meaning that the <Directory> directive with the closest matching path to the actual pathname of the file or directory in question is used. Per-directory configuration is inherited by all sub-directories until a closer matching <Directory> is encountered, at which time the original per-directory configuration is replaced with the closer match. Note that this does not apply to <Limit> </Limit> blocks, which are inherited by all sub-directories until a <Limit> block is reached in a closer match.

A trailing slash and wildcard ("/*") can be appended to the directory, specifying that the configuration block applies only to the contents (and sub-contents), not to the actual directory itself. Such wildcard matches always take precedence over non-wildcard <Directory> configuration blocks. <Directory> blocks cannot be nested (they are automatically nested at run-time based on their pathnames). Pathnames must always be absolute (except inside <Anonymous>), and should not reference symbolic links. Pathnames inside an <Anonymous> block can be relative, indicating that they are based on the anonymous root directory.

[Notes for ProFTPD 1.1.3 and later only] Pathnames that begin with the special character '~' and do not specify a username immediately after ~ are put into a special deferred mode. When in deferred mode, the directory context is not hashed and sorted into the configuration tree at boot time, but rather this hashing is deferred until a user authenticates, at which time the '~' character is replaced with the user's home directory. This allows a global <Directory> block which applies to all user's home directories, or sub-directories thereof. This feature is not supported within an <Anonymous> block.

See also

Limit

Examples

#Default usage of the directory directive
<Directory /users/robroy/private>
  HideNoAccess on
</Directory>

#Example with username-expanding
<Directory ~/anon-ftp>
  <Limit WRITE>
    DenyAll
  </Limit>
</Directory>

Description

DirFakeGroup can be used to hide the true group of files (including directories, fifos, etc.) in a directory listing. If simply turned On, DirFakeGroup will display all files as being owned by group 'ftp'. Optionally, the groupname argument can be used to specify a specific group other than 'ftp'. "~" can be used as the argument in order to display the primary group name of the current user.

Both DirFakeGroup and DirFakeUser are completely cosmetic; the groupname or username specified don't need to exist on the system, and neither directive affects permissions, real ownership or access control in any way.

See also

DirFakeUser DirFakeMode

Examples

Description

The DirFakeMode directive configures a mode (or permissions) which will be displayed for ALL files and directories in directory listings. For each subset of permissions (user, group, other), the "execute" permission for directories is added in listings if the "read" permission is specified by this directive. As with DirFakeUser, and DirFakeGroup, the "fake" permissions shown in directory listings are cosmetic only, they do not affect real permissions or access control in any way on the server. Note that DirFakeMode can affect the real permissions, for example, for FTP mirroring tools. Such tools tend to create a mirror from what the tool sees (e.g. DirFakeMode permissions) on the source FTP server.

See also

DirFakeUser DirFakeGroup

Examples

  DirFakeMode 0640

Will result in:

  -rw-r----- ... arbitrary.file
  drwxr-x--- ... arbitrary.directory

Description

DirFakeUser can be used to hide the true user owners of files (including directories, fifos, etc.) in a directory listing. If simply turned On, DirFakeUser will display all files as being owned by user 'ftp'. Optionally, the username argument can be used to specify a specific user other than 'ftp'. "~" can be used as the argument in order to display the current user's username.

Both DirFakeGroup and DirFakeUser are completely cosmetic; the groupname or username specified don't need to exist on the system, and neither directive affects permissions, real ownership or access control in any way.

See also

DirFakeGroup DirFakeMode

Examples

Description

DisplayChdir, DisplayConnect, DisplayLogin and DisplayQuit support the following "magic cookies" (only in 0.99.0pl10 and later), which are replaced with their respective strings before being displayed to the user.

%C	Current working directory

%E	Server admin's e-mail address

%F	Available space on file system, in bytes

%f      Available space on file system, with units

%i      The number of files uploaded (input) in this session

%K	Total number of bytes transferred

%k	Total number of bytes transferred, in units

%L	Local host name

%M	Max number of authenticated clients

%N	Current number of authenticated clients

%o      The number of files downloaded (output) in this session

%R	Remote host name

%T	Current Time

%t      The number of files transfered (uploaded and downloaded) in this session

%U	Username originally used in login

%u	Username reported by ident protocol

%V	Name of virtual host (if any)

%x	The name of the user's class

%y	Current number of connections from the user's class

%z	Max number of connections from the user's class

%{total_bytes_in} The number of bytes uploaded (input) in this session

%{total_bytes_out} The number of bytes downloaded (output) in this session

%{total_bytes_xfer} The number of bytes transferred (uploaded and downloaded) in this session

%(total_files_in} The number of files uploaded (input) in this session

%(total_files_out} The number of files downloaded (output) in this session

%(total_files_xfer} The number of files transferred (uploaded and downloaded) in this session

NOTE: not all of these may have a rational value, depending on the context in which they're used (e.g., %u if ident lookups are off).

See also

DisplayConnect DisplayLogin DisplayQuit

Examples

#Old way in the spirit of DisplayFirstChdir
DisplayChdir /home/ftp/filetodisplay true

Description

The DisplayConnect directive configures an ASCII text filename which will be displayed to the user when they initially connect but before they login. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for starting in the home directory of the user the server is running as. As this can lead confusion, absolute pathnames are suggested. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client.

See also

DisplayFirstChdir

Examples

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

Description

The DisplayGoAway directive specifies an ASCII text filename which will be displayed to the user if the class they're a member of has too many users logged in and their login request has been denied. DisplayGoAway supports the same "magic cookies" as DisplayFirstChdir.

See also

DisplayFirstChdir

Examples

Description

The DisplayLogin directive configures an ASCII text filename which will be displayed to the user when they initially login. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for in the initial directory a user is placed in immediately after login (home directory for unix user logins, anonymous-root directory for anonymous logins). Note: that for jailed logins, the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client. DisplayLogin supports the same "magic cookies" as DisplayFirstChdir.

See also

DisplayFirstChdir

Examples

Description

DisplayQuit configures an ASCII text filename which will be displayed to the user when they quit. The filename can be either relative or absolute. In the case of a relative filename, the file is searched for in current directory a user is in when they logout -- for this reason, a absolute filename is usually preferable. NOTE: for jailed logins, the file must reside inside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs and nothing is logged or displayed to the client. DisplayQuit supports the "magic cookies" listed under DisplayFirstChdir.

See also

DisplayFirstChdir

Examples

Description

Module: mod_readme The DisplayReadme directive notifies the user of the last change date of the specified file or pattern. Only a single DisplayReadme directive is allowed per configuration scope. DisplayReadme README Will result in: Please read the file README it was last modified on Sun Oct 17 10:36:14 1999 - 0 days ago Being displayed to the user on a cwd. DisplayReadmePattern README* Will result in: Please read the file README it was last modified on Tue Jan 25 04:47:48 2000 - 0 days ago Please read the file README.first it was last modified on Tue Jan 25 04:48:04 2000 - 0 days ago Being displayed to the user on a cwd.

See also

Examples

Description

The ExtendedLog directive allows customizable logfiles to be generated, either globally or per VirtualHost. The filename argument must contain an absolute pathname to a logfile which will be appended to when proftpd starts; the pathname should not be to a file in a nonexistent directory, to a world-writeable directory, or be a symbolic link (unless AllowLogSymlinks is set to on). Multiple logfiles (potentially with different command classes and formats) can be created. Optionally, the command-classes argument can be used to control which types of commands are logged. If not command classes are specified, proftpd logs all commands by default (passwords are hidden). command-classes is a comma delimited (no whitespace!) list of which commands to log.

The following are valid classes: NONE No commands AUTH Authentication commands (ACCT, PASS, REIN, USER) INFO Informational commands (FEAT, HELP, MDTM, QUIT, PWD, STAT, SIZE, SYST, XPWD) DIRS Directory commands (CDUP, CWD, LIST, MKD, NLST, RMD, XCWD, XCUP, XMKD, XRMD) READ File reading (RETR) WRITE File/directory writing or creation (APPE, MKD, RMD, RNFR, RNTO, STOR, STOU, XMKD, XRMD) MISC Miscellaneous commands (ABOR, ALLO, EPRT, EPSV, MODE, NOOP, OPTS, PASV, PORT, REST, RNFR, RNTO, SITE, SMNT, STRU, TYPE) SEC RFC2228-related security FTP commands ALL All commands (default)

If a format-nickname argument is supplied, ExtendedLog will use the predefined logformat (created by LogFormat). Otherwise, the default format of "%h %l %u %t \"%r\" %s %b" is used.

See also

AllowLogSymlinks, LogFormat, TransferLog

Examples

For example, to log all read and write operations to /var/log/ftp.log (using the default format), you could:

ExtendedLog /var/log/ftp.log read,write

Description

The FileRatioErrMsg directive .... Example: FileRatioErrMsg

See also

Examples

Description

The Global configuration block is used to create a set of configuration directives which is applied universally to both the main server configuration and all VirtualHost configurations. Most, but not all other directives can be used inside a Global block.

In addition, multiple <Global> blocks can be created. At runtime, all Global blocks are merged together and finally into each server's configuration. Global blocks are terminated by a matching </Global> directive.

See also

Examples

Description

The Group directive configures which group the server daemon will normally run at. See User for more details.

See also

Examples

Description

The GroupOwner directive configures which group all newly created directories and files will be owned by, within the context that GroupOwner is applied to. The group ID of groupname cannot be 0. Note that GroupOwner cannot be used to override the host OS/file system user/group paradigm. If the current user is not a member of the specified group, new files and directories will not be able to be chown()ed to the GroupOwner group. If this happens, file STOR (send file from client to server) and MKD/XMKD (mkdir) operations will succeed normally, however the new directory entries will be owned by the current user's default group (a warning message is also logged) instead of by the desired group. If you also use UserOwner in the same context, this restriction is lifted.

See also

UserOwner

Examples

Description

The GroupRatio directive .... Example: GroupRatio

See also

Examples

Description

The HiddenStores directive enables two-step file uploads: files are uploaded as ".in.filename." and once the upload is complete, renamed to just "filename". This provides a degree of atomicity and helps prevent 1) incomplete uploads and 2) files being used while they're still in the progress of being uploaded.

Note: if the temporary file name is already in use (e.g., a server crash during upload), it will prevent the file from being uploaded

The REST (Restart STOR) command is automatically blocked when HiddenStores is enabled, with the server returning a 501 error code to the client.

See also

AllowStoreRestart DeleteAbortedStores

Description

The HideFiles directive configures a <Directory> section to hide all directory entries, e.g. its files and sub-directories, that match the given regular expression. These files can still be operated on by other FTP commands (DELE, RETR, etc), as constrained by any applicable <Limit>s, but this can be modified using the IgnoreHidden directive. Note that this directive manipulates a file's "hidden-ness", but doesn't do any hiding by itself. A <Limit> section, with IgnoreHidden enabled, does the actual hiding of the files from the <Limit>ed commands.

As <Directory> configurations are inherited by sub-directories, the "none" parameter can be used to disable any inherited file hiding within a sub-directory, usually through the use of a .ftpaccess file.

The optional parameters are used to restrict the rule for hiding files only to specific users. If "user" restriction is given, then expression is a user-expression specifying to which users the rule applies. Similarly for the "group" restriction. For the "class" restriction, the expression is simply the name of connection class for whom the rule will apply.

Examples:

  # Hide configuration and passwd files from view
  HideFiles "(\\.conf|passwd)$"

  # ...or the same regex, without the quotes
  HideFiles (\.conf|passwd)$

  # Hide those same files from everyone _except_ a special user
  HideFiles (\.conf|passwd)$ user !tj

  # Using the ! prefix to "invert" the regular expression matching,
  # allow only .txt and .html files to be seen
  HideFiles !(\.txt|\.html)$

  # Only let users of the webmaster group see HTML files, but nothing else
  HideFiles !(\.htm|\.html)$ group webmaster

See Also: HideGroup, HideUser, HideNoAccess

Description

The HideGroup directive configures a <Directory> or < Anonymous> block to hide all directory entries owned by the specified group, unless the group is the primary group of the currently logged-in, authenticated user . Normally, hidden directories and files cannot be seen via LIST or NLST commands but can be operated on via other FTP commands (CWD, DELE, RETR, etc). This behavior can be modified via the IgnoreHidden directive.

See also

See Also: HideUser, HideNoAccess, IgnoreHidden

Examples

Description

The HideNoAccess directive configures a <Directory> or <Anonymous> block to hide all directory entries in a directory listing (via the LIST or NLST FTP commands) to which the current logged-in, authenticated user has no access. Normal Unix-style permissions always apply, so that although a user may not be able to see a directory entry that has HideNoAccess applied, they will receive a normal "Permission denied" error message when attempting to blindly manipulate the file system object. The directory or file can be made completely invisible to all FTP commands by applying IgnoreHidden in conjunction with HideNoAccess.

See also

See Also: HideUser, HideGroup, IgnoreHidden

Examples

Description

The HideUser directive configures a <Directory> or <Anonymous> block to hide all directory entries owned by the specified user, unless the owning user is the currently logged-in, authenticated user. Normally, hidden directories and files cannot be seen via LIST or NLST commands but can be operated on via other FTP commands (CWD, DELE, RETR, etc). This behavior can be modified via the IgnoreHidden directive.

See also

HideGroup, HideNoAccess, IgnoreHidden

Examples

Description

The HostRatio directive .... Example: HostRatio

See also

Examples

Description

Normally, when a client initially connects to proftpd, the ident protocol (RFC1413) is used to attempt to identify the remote username. This can be controlled via the IdentLookups directive.

See also

Examples

Description

The <IfDefine test>...</IfDefine> section is used to mark directives that are conditional. The directives within an IfDefine section are only processed if the test is true. If the test is false, everything between the start and end markers is ignored.

The test in the <IfDefine> section directive can be one of two forms: 'parameter-name' or '!parameter-name'

In the former case, the directives between the start and end markers are only processed if the parameter named parameter-name is defined. The second format reverses the test, and only processes the directives if parameter-name is not defined.

The parameter-name argument is a define as given on the command line via -Dparameter-name, at the time the server was started.

<IfDefine> sections are nest-able, which can be used to implement simple multiple-parameter tests.

See also

Define, IfModule

Examples

$ proftpd -DDoSomething

--[ proftpd.conf ]--
<IfDefine DoSomething>
# do something here
</IfDefine>
--[ end ]--

Description

The <IfModule test>...</IfModule> section is used to mark directives that are conditional. The directives within an IfModule section are only processed if the test is true. If the test is false, everything between the start and end markers is ignored.

The test in the <IfModule> section directive can be one of two forms: "module name" or "!module name"

In the former case, the directives between the start and end markers are only processed if the module named module name is compiled in to ProFTPD. The second format reverses the test, and only processes the directives if module name is not compiled in.

The module name argument is a module name as given as the file name of the module, at the time it was compiled. For example, mod_sql.c.

<IfModule> sections are nest-able, which can be used to implement simple multiple-module tests.

See also

Define, IfDefine

Examples

<IfModule mod_load.c>
MaxLoad                 10 "Access denied, server load too high"
</IfModule>

Description

Normally, files hidden via HideNoAccess, HideUser or HideGroup can be operated on by all FTP commands (assuming Unix file permissions allow access), even though they do not appear in directory listings. Additionally, even when normal file system permissions disallow access, proftpd returns a "Permission denied" error to the client, indicating that the requested object does exist, even if it cannot be acted upon. IgnoreHidden configures a <Limit> block to completely ignore any hidden directory entries for the set of limited FTP commands. This has the effect of returning an error similar to "No such file or directory" when the client attempts to use the limited command upon a hidden directory or file.

See also

Examples

Description

This directive allows you to include another configuration file within your current configuration file. The given file argument must be the full path to the file to be included.

See also

Examples

Description

Should be one of never, always, search, or find to specify that aliases are never dereferenced, always dereferenced, dereferenced when searching, or dereferenced only when locating the base object for the search.

Examples

LDAPAliasDereference always

Description

FIXMEFIXMEFIXME

This dicrective has to be set before any of the LDAPDo* directives.

See also

Examples

FIXFIXFIX

FIXFIX

Description

By default, the DN specified by LDAPDNInfo will be used to bind to the LDAP server to obtain user information, including the userPassword attribute. If LDAPAuthBinds is set to on, the DN specified by LDAPDNInfo will be used to fetch all user information except the userPassword attribute. Then, mod_ldap will bind to the LDAP server as the user who is logging in via FTP with the user-supplied password. If this bind succeeds, the user is considered authenticated and is allowed to log in. This method of LDAP authentication has the added benefit of supporting any password encryption scheme that your LDAP server supports.

See also

Examples

Description

Specifies the authentication scheme used for passwords with no {prefix} in the LDAP database. For example, if you are using something like userPassword: mypass in your LDAP database, you would want to set LDAPDefaultAuthScheme to clear.

See also

Examples

Description

This directive is useful primarily in virtual-user environments common in large-scale ISPs and hosting organizations. If a user does not have a LDAP gidNumber attribute, the LDAPDefaultGID is used. This allows one to have a large number of users in an LDAP database without gidNumber attributes; setting this configuration directive will automatically assign those users a single GID.

See also

Examples

Description

This directive is useful primarily in virtual-user environments common in large-scale ISPs and hosting organizations. If a user does not have a LDAP uidNumber attribute, the LDAPDefaultUID is used. This allows one to have a large number of users in an LDAP database without uidNumber attributes; setting this configuration directive will automatically assign those users a single UID.

See also

Examples

Description

This directive specifies the LDAP DN and password to use when binding to the LDAP server. If this configuration directive is not specified, anonymous binds are used.

See also

Examples

Description

This configuration directive activates LDAP authentication. The second argument to this directive is the LDAP base DN to use for authentication. The third argument is a template to be used for the search filter; %v will be replaced with the username that is being authenticated. By default, the search filter template "(&(uid=%v)(objectclass=posixAccount))" is used. The uid for the the search filter is taken from the LDAPAttr directive. Search filter templates are only supported in mod_ldap v2.7 and later.

See also

LDAPAttr

Examples

Description

This configuration directive activates LDAP GID-to-name lookups in directory listings. The second argument to this directive is the LDAP base DN to use for GID-to-name lookups. The third through fifth arguments are templates to be used for the search filter; %v will be replaced with the GID that is being looked up.

By default, the search filter templates look like this:

cn_filter: "(cn=%v)(objectclass=posixGroup))", gidnumber_filter: "(gidNumber=%v)(objectclass=posixGroup))", memberuid_filter: "(memberUid=%v)(objectclass=posixGroup))".

The attribute names used in the default search filters are taken from the LDAPAttr directive.

Filter templates are only supported in mod_ldap v2.8.3 and later.

See also

LDAPAttr

Examples

Description

Activates LDAP quota lookups. The second argument is the LDAP base DN to use for quota limit searches. The third argument is the search filter template. The default search filter template is "(&(LDAPAttr_uid=%u)(objectclass=posixAccount))". The attribute name used in the default search filter template is taken from the LDAPAttr directive, so if you re-map an attribute, the default search filter reflects that re-mapping.

In mod_ldap v2.7 or later, %u in the search filter template will be replaced with the username, group, or class that is being looked up. mod_ldap v2.9.3 or later will also expand %u in the base DN.

The optional default-quota argument specifies the quota limits to use if an entry does not have a ftpQuota attribute, and has the same format as the ftpQuota LDAP attribute. For example, "false,hard,100,100,100,100,100,100". This argument is deprecated as of ProFTPD 1.3.4b; use the >LDAPAttr

Examples

Description

This configuration directive activates LDAP UID-to-name lookups in directory listings. The second argument to this directive is the LDAP base DN to use for UID-to-name lookups. The third argument is a template to be used for the search filter; %v will be replaced with the UID that is being looked up. By default, the search filter template "(&(LDAPAttr_uidNumber=%v)(objectclass=posixAccount))" is used. The uid for the the search filter is taken from the LDAPAttr directive Search filter templates are only supported in mod_ldap v2.7 and later.

See also

LDAPAttr

Examples

Description

Even when a LDAPDefaultGID is configured, mod_ldap will allow individual users to have gidNumber attributes that will override this default GID. With LDAPForceDefaultGID enabled, all LDAP-authenticated users are given the default GID; GIDs may not be overridden by gidNumber attributes.

See also

Examples

Description

Even when a LDAPDefaultUID is configured, mod_ldap will allow individual users to have uidNumber attributes that will override this default UID. With LDAPForceDefaultUID enabled, all LDAP-authenticated users are given the default UID; UIDs may not be overridden by uidNumber attributes.

See also

Examples

Description

Even when a LDAPGenerateHomedirPrefix is configured, mod_ldap will allow individual users to have homeDirectory attributes that will override the default. With LDAPForceHomeDironDemand enabled, all LDAP-authenticated users are given the default prefix and/or suffix; homedirs may not be overridden by LDAP homeDirectory attributes.

See also

LDAPGenerateHomedir LDAPGenerateHomedirPrefix LDAPGenerateHomedirPrefixNoUsername

Examples

Description

This directive has been deprecated with mod_ldap v2.8.13. Please take a look at LDAPForceGeneratedHomedir

Even when a LDAPHomeDironDemandPrefix is configured, mod_ldap will allow individual users to have homeDirectory attributes that will override the default. With LDAPForceHomeDironDemand enabled, all LDAP-authenticated users are given the default prefix and/or suffix; homedirs may not be overridden by LDAP homeDirectory attributes.

See also

LDAPForceGeneratedHomedir

Examples

Description

LDAPGenerateHomedir activates on-demand home directory creation. If a user logs in and does not yet have a home directory, a home directory is created automatically.

In mod_ldap <= 2.7.6, the home directory will be owned by the same user and group that ProFTPD runs as (see the User and Group configuration directives). mod_ldap >= 2.8 can create home directories for users with any UID/GID, not just those with the same UID/GID as the main ProFTPD server.

The second argument allows you to specify the mode (default permissions) to use when creating home directories on demand, subject to ProFTPD's umask (see the Umask directive). If no directory mode is specified, the default of 0755 is used. Directory mode setting is only supported in mod_ldap v2.7 or later.

See also

LDAPForceGeneratedHomedir LDAPGenerateHomedirPrefix LDAPGenerateHomedirPrefixNoUsername

Examples

Description

LDAPGenerateHomedirPrefix enables a prefix to be specified for on-demand home directory creation. This is most useful if mod_ldap is being used to authenticate against an LDAP directory that does not return a homeDirectory attribute, either because it cannot (Microsoft Active Directory, for example) or because you do not wish to extend your existing directory schema.

For example, setting this directive to "/home" and logging in as the user "joe" would result in his home directory being created as "/home/joe". The directory will be created with the mode specified in LDAPGenerateHomedir. To use this directive, LDAPGenerateHomedir must be enabled.

See also

LDAPForceGeneratedHomedir LDAPGenerateHomedir LDAPGenerateHomedirPrefixNoUsername

Examples

Description

(docs incomplete)

See also

LDAPForceGeneratedHomedir LDAPGenerateHomedir LDAPGenerateHomedirPrefix

Description

Activates LDAP group membership lookups and GID to name mappings in directory listings.

The first argument is the LDAP base DN to use for group lookups. The second through fourth arguments are search filter templates; %u will be replaced with the group name, GID number, or group member username that is being looked up, respectively.

The default search filter templates are:

group-name-filter-template: "(cn=%u)(objectclass=posixGroup))", gid-number-filter-template: "(gidNumber=%u)(objectclass=posixGroup))", member-user-filter-template: "(memberUid=%u)(objectclass=posixGroup))".

The attribute names used in the default search filters are taken from the LDAPAttr directive, so if you re-map an attribute, the default search filter reflects that re-mapping.

See also

LDAPAttr

Examples

Description

LDAPHomedirOnDemand activates on-demand home directory creation. If a user logs in and does not yet have a home directory, a home directory is created automatically.

In mod_ldap <= 2.7.6, the home directory will be owned by the same user and group that ProFTPD runs as (see the User and Group configuration directives). mod_ldap >= 2.8 can create home directories for users with any UID/GID, not just those with the same UID/GID as the main ProFTPD server.

The second argument allows you to specify the mode (default permissions) to use when creating home directories on demand, subject to ProFTPD's umask (see the Umask directive). If no directory mode is specified, the default of 0755 is used. Directory mode setting is only supported in mod_ldap v2.7 or later.

See also

LDAPGenerateHomedir

Examples

Description

LDAPHomedirOnDemandPrefix enables a prefix to be specified for on-demand home directory creation. This is most useful if mod_ldap is being used to authenticate against an LDAP directory that does not return a homeDirectory attribute, either because it cannot (Microsoft Active Directory, for example) or because you do not wish to extend your existing directory schema.

For example, setting this directive to "/home" and logging in as the user "joe" would result in his home directory being created as "/home/joe". The directory will be created with the mode specified in LDAPHomedirOnDemand. To use this directive, LDAPHomedirOnDemand must be enabled.

See also

LDAPGenerateHomedirPrefix

Examples

Description

(docs incomplete)

See also

LDAPGenerateHomedirPrefixNoUsername

Description

to be created within a user's home directory when it is created on demand. For example, if a user's home directory is "/home/user", setting this configuration directive to "public_html" will also create "/home/user/public_html" on demand. In mod_ldap v2.7.6 and earlier, you must also activate LDAPHomedirOnDemand in your configuration.

mod_ldap >= 2.8 supports multiple suffix arguments and does not require LDAPHomedirOnDemand to be enabled.

mod_ldap >= 2.8.11 supports additional mode information; you can add ":octal-mode" to a directory argument to have it created with that mode. For example, LDAPHomedirOnDemandSuffix foo:700 will create the suffix directory foo with the mode 700.

See also

Examples

Description

LDAPNegativeCache specifies whether or not to cache negative responses from the LDAP server when using LDAP for UID/GID lookups. This option is useful if you also use/are in transition from another authentication system; if there are many users in your old authentication system that aren't in the LDAP database, there can be a significant delay when a directory listing is performed as the UIDs not in the LDAP database are repeatedly looked up in an attempt to present usernames instead of UIDs in directory listings. With LDAPNegativeCache set to on, negative ("not found") responses from the LDAP server will be cached and speed will improve on directory listings that contain many users not present in the LDAP database.

See also

Examples

Description

FIX FIX FIX

See also

Examples

FIXFIXFIX

FIXFIX

Description

Sets the timeout used for LDAP directory queries. The default is the default timeout used by your LDAP API.

See also

Examples

Description

Set the scope used for LDAP searches. The default setting, subtree, searches for all entries in the tree from the current level down. Setting this directive to onelevel searches only one level deep in the LDAP tree.

See also

Examples

Description

LDAPServer allows you to to specify the hostname(s) and port(s) of the LDAP server(s) to use for LDAP authentication. If no LDAPServer configuration directive is present, the default LDAP servers specified by your LDAP API will be used.

Note that the default search scope for LDAP URLs is 'base' if a scope is not explicitly specified in the URL. This behavior differs from the LDAPSearchScope directive, which defaults to 'subtree'.

See also

Examples

Description

Activates LDAP authentication and UID to name mappings in directory listings.

The first argument is the LDAP base DN to use for user lookups. During authentication, %u will be replaced with the username that is being authenticated. When looking up users by UID number, %u will not be replaced. Usually, %u in the base DN is only useful in "virtual user" environments, since mod_ldap won't be able to look up other users.

The second argument is the search filter template for looking up users by username; %u will be replaced with the username that is being authenticated.

The third argument is the search filter template for looking up users by UID number; %u will be replaced with the UID number that is being looked up.

The default search filter templates are:

username-filter-template: "(uid=%u)(objectclass=posixAccount))", uid-number-filter-template: "(uidNumber=%u)(objectclass=posixAccount))",

The attribute names used in the default search filters are taken from the LDAPAttr directive, so if you re-map an attribute, the default search filter reflects that re-mapping.

See also

LDAPAttr

Examples

Description

By default, mod_ldap connects to the LDAP server via a non-encrypted connection. Enabling this option causes mod_ldap to use an encrypted (TLS/SSL) connection to the LDAP server. If a secure connection to the LDAP server fails, mod_ldap will not authenticate users (mod_ldap will *not* fall back to an unsecure connection).

See also

Examples

Description

The LeechRatioMsg directive defines the response message sent back to the client upon breaking their quota limits.

See also

Examples

LeechRatioMsg "please upload as well as download"

Description

The Limit configuration block is used to place access restrictions on one or more FTP commands, within a given context. Limits flow downward, so that a Limit configuration in the server config context applies to all <Directory> and <Anonymous> blocks that also reside in the configuration; until it is overridden by a "lower" <Limit> block. Any number of command parameters can be specified, against which the contents of the <Limit> block will be applied. command can be any valid FTP command, but is generally one of the following: CWD (Change Working Directory) Sent by client when changing directories. MKD / XMKD (MaKe Directory) Sent by client to create a new directory. RNFR (ReName FRom), RNTO (ReName TO) Sent as a pair by client to rename a directory entry. DELE (DELEte) Sent by client to delete a file. RMD / XRMD (ReMove Directory) Sent by client to remove a directory. RETR (RETRieve) Transfer a file from the server to the client. STOR (STORe) Transfer a file from the client to the server. In addition, the following command-groups are accepted. They have a lower precedence than real commands, meaning that a real command limit will always be applied instead of the command-group. READ All FTP commands which deal with file reading (directory listing not included): RETR, SITE, SIZE, STAT WRITE All FTP commands which deal with file or directory write/creation/deletion: APPE, DELE, MKD, RMD, RNTO, STOR, XMKD, XRMD DIRS All FTP commands which deal with directory listing: CDUP, CWD, LIST, MDTM, NLST, PWD, RNFR, XCUP, XCWD, XPWD ALL ALL FTP commands (identical to READ WRITE DIRS). Note this group has the lowest precedence of all; it will not override a limit imposed by another command-group (e.g. DIRS). Finally, a special command is allowed which can be used to control login access: LOGIN Connection or login to the server. Applying a <Limit> to this pseudo-command can be used to allow or deny initial connection or login to the context. It has no effect, and is ignored, when used in a context other than server config, <VirtualHost> or <Anonymous> (i.e. using it in a <Directory> context is meaningless). <Limit> command restrictions should not be confused with file/directory access permission. While limits can be used to restrict a command on a certain directory, they cannot be used to override the file permissions inherent to the base operating/file system. The following FTP commands cannot be restricted via <Limit>: ABOR HELP MODE (not implemented, always S) NOOP PASS (use <Limit LOGIN>) PASV PORT QUIT REST (use AllowRetrieveRestart, AllowStoreRestart) STRU (not implemented, always F) SYST TYPE USER (use <Limit LOGIN>)

See also

See Also: IgnoreHidden

Examples

Description

Normally, FTP commands involving directory listings (NLST, LIST and STAT) use the arguments (options) passed by the client to determine what files are displayed and the format they are displayed in. The ListOptions directive can alter the behaviour of such listings by making it such that a certain option (or options) is always in effect, or is always disabled.

In addition to the normal dash-prefixed options that the builtin ls takes, the directive allows for plus-prefixed options. The plus-prefixed options allow for their dash-prefixed equivalents, potentially given by a user, to be disabled, while still allowing other options to function normally.

      -1 List one file per line

      -A List all files except "." and ".."
    
      -a List all files including those whose names start with "."
    
      -C List entries by columns
    
      -d List directory entries instead of directory contents
    
      -F Append file type indicator (one of "*", "/", "=", "@" or "|") to names
    
      -h Print file sizes in human-readable format (e.g. 1K, 234M, 2G)
    
      -L List files pointed to by symlinks
    
      -l Use a long listing format
    
      -n List numeric UIDs/GIDs instead of user/group names
    
      -R List subdirectories recursively
    
      -r Sort filenames in reverse order
    
      -S Sort by file size
    
      -t Sort by modification time 

If the optional "strict" keyword is used, then the configured options will override any options given by the user (i.e. the user's options will be ignored). In addition to "strict" the following keywords are supported:

      maxfiles Sets a maximum limit on the number of files listed in one directory listing

      maxdirs Sets a maximum limit on the number of directories listed in one directory listing

      maxdepth Sets a maximum recursion depth, if the -R option is allowed 

See also

Examples

# Force directory listings to always show dotfiles ListOptions "-a"

# To prevent anyone from doing recursive listings, but still allowing # other user options, use +R to disable any -R option given by users ListOptions "+R"

# To allow only the basic listing, no options, always ListOptions "" strict

#limit maximum files given back to 2000 and recurse in to a max #depth of 3 directories ListOptions -a maxfiles 2000 maxdepth 3

Description

The LogFormat directive can be used to create a custom logging format for use with the ExtendedLog directive. Once created, the format can be referenced by the specified nickname. The format-string argument can consist of any combination of letters, numbers and symbols. The special character % is used to start a meta-sequence (see below). To insert a literal % character, use %%.

The following meta sequences are available and are replaced as indicated when logging.

%a		Remote client IP address
%A		Anonymous username (password given), or UNKNOWN if non-anonymous
%b		Bytes sent for request
%d		Directory name (not full path) for CDUP, CWD, MKD, RMD, XCWD, XCUP, XMKD, XRMD
%D		Directory name (full path) for CDUP, CWD, MKD, RMD, XCWD, XCUP, XMKD, XRMD
%{FOOBAR}e	  Contents of environment variable FOOBAR.  Note that the server does not set any environment variables itself.
%f		  Filename stored or retrieved, absolute path (not chrooted)
%F		  Filename stored or retrieved, as the client sees it
%h		  Remote client DNS name
%J		  Command arguments received from client, e.g. file.txt
%l		  Remote username (from ident), or UNKNOWN if ident lookup failed
%L		  Local server IP address
%m		  Command (method) name received from client, e.g. RETR
%p		  Local server port number
%P		  Local server process id (pid)
%r		  Full command line received from client
%s		  Numeric FTP response code (status)
%S		  Response message send from the client (available since v1.3.1rc1)
%t		  Current local time
%{format}t	  Current local time formatted (strftime(3) format)
%T		  Time taken to transmit/receive file, in seconds 
%u		  Local authenticated userid
%U		  USER name originally sent by the client
%v		  ServerName of server handling session
%V		  DNS name of server handling session
%{version}	  Print ProFTPD Version
%{protocol}       Protocol used

See also

ExtendedLog, TransferLog

Examples

Description

MasqueradeAddress causes the server to display the network information for the specified IP address or DNS hostname to the client, on the assumption that that IP address or DNS host is acting as a NAT gateway or port forwarder for the server.

See also

Examples

    MasqueradeAddress nat-gw.mydomain.com

Description

The MaxClients directive configures the maximum number of authenticated clients which may be logged into a server or anonymous account. Once this limit is reached, additional clients attempting to authenticate will be disconnected. The special value none may be supplied which removes all maximum connection limits from the applicable configuration context. Additionally, an optional message argument may be used which will be displayed to a client attempting to exceed the maximum value; immediately before disconnection. The message argument is parsed for the magic string "%m", which is replaced with the configured maximum value. If message is not supplied, a system-wide default message is used. Example: MaxClients 5 "Sorry, the maximum number of allowed users are already connected (%m)" Results in: 530 Sorry, the maximum number of allowed users are already connected (5)

See also

Examples

Description

The MaxClientsPerClass directive configures the maximum number of clients that may be connected at any given time from the same Class. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number of clients (%m) from your class are already connected."

See also

MaxClients, MaxClientsPerHost MaxClientsPerUser MaxHostsPerUser

Examples

MaxClientsPerClass foo 1 "Only one such client at a time."
Results in: 530 Only one such client at a time.

Description

The MaxClientsPerHost directive configures the maximum number of clients allowed to connect per host. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number clients (%m) from your host are already connected." is used.

See also

MaxClients, MaxHostsPerUser

Examples

MaxClientsPerHost 1 "Sorry, you may not connect more than one time."
Results in: 530 Sorry, you may not connect more than one time.

Description

The MaxClientsPerUser directive configures the maximum number of clients that may be connected at any given time using the same user name. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number of clients (%m) for this user already connected."

See also

MaxClients, MaxClientsPerHost MaxHostsPerUser

Examples

MaxClientsPerUser 1 "Only one such user at a time."
Results in: 530 Only one such user at a time.

Description

Set the maxiumum rate at which new TCP connections are accepted, this applies to the entire server, therefore too low a value on a high traffic server can result in all VirtualHosts being made unavailable due to normal traffic levels.

The value is the number of connections in a given second at which the block comes into effect, thus a value of "1" will result in all connections being blocked.

See also

Examples

MaxConnectionRate 4

Description

The MaxConnectionsPerHost directive configures the maximum number of unauthenticated clients allowed to connect per host. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number of connections (%m) from your host are already connected." is used.

See also

MaxClients, MaxClientsPerHost, MaxHostsPerUser

Examples

MaxConnectionsPerHost 1 "Sorry, you may not connect more than one time."
Results in: 530 Sorry, you may not connect more than one time.

Description

The MaxHostsPerUser directive configures the maximum number of times different hosts, using a given login, can connect at any given time. The optional argument message may be used which will be displayed to a client attempting to exceed the maximum value. If message is not supplied, a default message of "Sorry, the maximum number of hosts (%m) for this user already connected."

See also

MaxClients, MaxClientsPerHost

Examples

MaxHostsPerUser 1 "Sorry, you may not connect more than one time."
Results in: 530 Sorry, you may not connect more than one time.

Description

The MaxInstances directive configures the maximum number of child processes that may be spawned by a parent proftpd process in standalone mode. The directive has no effect when used on a server running in inetd mode. Because each child proftpd process represents a single client connection, this directive also controls the maximum number of simultaneous connections allowed. Additional connections beyond the configured limit are syslog'd and silently disconnected. The MaxInstances directive can be used to prevent undesirable denial-of-service attacks (repeatedly connecting to the ftp port, causing proftpd to fork-bomb). By default, no limit is placed on the number of child processes that may run at one time.

See also

Examples

Description

The MaxLoginAttempts directive configures the maximum number of times a client may attempt to authenticate to the server during a given connection. After the number of attempts exceeds this value, the user is disconnected and an appropriate message is logged via the syslog mechanism.

See also

Examples

Description

When downloading files to clients (eg serving a RETR request), the server will check for any configured limit against the size of the file being requested, and abort any transfers if the requested file's size exceeds the configured limit.

A single "*" argument configures unlimited file sizes, and is used primarily to override any inherited restrictions from higher contexts. The given number is the number of bytes for the limit, and is followed by a units specifier of (case-insensitive) "Gb" (Gigabytes), "Mb" (Megabytes), "Kb" (Kilobytes), or "B" (bytes). The given number of bytes is multiplied by the appropriate factor.

The optional parameters are used to restrict the file size limits only to specific users. If the "user" restriction is given, then expression is a user-expression specifying to which users the rule applies. Similarly for the "group" restriction. For the "class" restriction, the expression is simply the name of connection class for whom the rule will apply. If no matching user, group, or class expression is found for the current user (in that order), then a limit with no expression (i.e. no "user", "group", or "class" identifier) is applied.

See Also: MaxStoreFileSize

See also

Examples

  # Restrict downloads to only 1 gigabyte
  MaxRetrieveFileSize 1 Gb

  # Restrict downloads for user fred, but allow unlimited download size for
  # everyone else
  MaxStoreFileSize 50 Kb user fred
  MaxStoreFileSize *

Description

When uploading files from a client (eg serving a STOR request), the server will check for any configured limit against the size of the file being sent, and abort any transfers if/when the given file's size exceeds the configured limit.

A single "*" argument configures unlimited file sizes, and is used primarily to override any inherited restrictions from higher contexts. The given number is the number of bytes for the limit, and is followed by a units specifier of (case-insensitive) "Gb" (Gigabytes), "Mb" (Megabytes), "Kb" (Kilobytes), or "B" (bytes). The given number of bytes is multiplied by the appropriate factor.

The optional parameters are used to restrict the file size limits only to specific users. If the "user" restriction is given, then expression is a user-expression specifying to which users the rule applies. Similarly for the "group" restriction. For the "class" restriction, the expression is simply the name of connection class for whom the rule will apply. If no matching user, group, or class expression is found for the current user (in that order), then a limit with no expression (ie no "user", "group", or "class" identifier) is applied.

See Also: MaxRetrieveFileSize

See also

Examples

  # Restrict upload to only 3 megabytes
  MaxStoreFileSize 3 Mb

  # Restrict anonymous uploads to 50k, but allow unlimited upload size for
  # everyone else
  MaxStoreFileSize 50 Kb user anonymous
  MaxStoreFileSize *

Description

By default, proftpd sends multiline responses as per RFC 959, i.e.: 200-First line More lines... 200 Last line RFC 2228 specifies that "6xy" response codes will be sent as follows: 600-First line 600-More lines... 600 Last line Note that 2228 ONLY specifies this for response codes starting with '6'. Enabling this directive causes ALL responses to be sent in this format, which may be more compatible with certain web browsers and clients. Also note that this is NOT the same as wu-ftpd's multiline responses, which do not comply with any RFC. Using this method of multilines is more likely to be compatible with all clients, although it isn't strictly RFC, and is thus not enabled by default.

See also

Examples

Description

The Order directive configures the order in which Allow and Deny directives are checked inside of a <Limit> block. Because Allow directives are permissive, and Deny directives restrictive, the order in which they are examined can significantly alter the way security functions. If the default setting of allow,deny is used, "allowed" access permissions are checked first. If an Allow directive explicitly allows access to the <Limit> context, access is granted and any Deny directives are never checked. If Allow did not explicitly permit access, Deny directives are checked. If any Deny directive applies, access is explicitly denied. Otherwise, access is granted. When deny,allow is used, "deny" access restrictions are checked first. If any restriction applies, access is denied immediately. If nothing is denied, Allow permissions are checked. If an Allow explicitly permits access, access to the entire context is permitted; otherwise access is implicitly denied. For clarification, the following illustrates the steps used when checking Allow/Deny access: Order allow,deny Check Allow directives. If one or more apply, exit with result: ALLOW Check Deny directives. If one or more apply, exit with result: DENY Exit with default implicit ALLOW Order deny,allow Check Deny directives. If one or more apply, exit with result: DENY Check Allow directives. If one or more apply, exit with result: ALLOW Exit with default implicit: DENY

See also

Examples

Description

PassivePorts restricts the range of ports from which the server will select when sent the PASV command from a client. The server will randomly choose a number from within the specified range until an open port is found. Should no open ports be found within the given range, the server will default to a normal kernel-assigned port, and a message logged.

The port range selected must be in the non-privileged range (eg. greater than or equal to 1024); it is STRONGLY RECOMMENDED that the chosen range be large enough to handle many simultaneous passive connections (for example, 49152-65534, the IANA-registered ephemeral port range).

See also

Examples

# Use the IANA registered ephemeral port range
PassivePorts 49152 65534

Description

PathAllowFilter allows the configuration of a regular expression that must be matched for all newly uploaded (stored) files. The regular expression is applied against the entire pathname specified by the client, so care must be taken when creating a proper regex. Paths that fail the regex match result in a "Forbidden filename" error being returned to the client. If the regular-expression argument contains whitespace, it must be enclosed in quotes.

See also

PathDenyFilter

Examples

# Only allow a-z 0-9 . - _ in file names,
PathAllowFilter ^[a-z0-9._-]+$

# as above but with upper case characters as well
PathAllowFilter ^[A-Za-z0-9._-]+$

Description

Similar to PathAllowFilter, PathDenyFilter specifies a regular expression which must not match any uploaded pathnames. If the regex does match, a "Forbidden filename" error is returned to the client. This can be especially useful for forbidding .ftpaccess or .htaccess files.

See also

PathAllowFilter

Examples

# We don't want .ftpaccess or .htaccess files to be uploaded
PathDenyFilter "(\\.ftpaccess|\\.htaccess)$"

Description

The PersistentPasswd directive controls how proftpd handles authentication, user/group lookups, and user/group to name mapping. If set to "on", proftpd will attempt to open the system-wide /etc/passwd, /etc/group (and /etc/shadow, potentially) files itself, holding them open even during a chroot()ed login. Note that /etc/shadow is never held open, for security reasons). On some platforms, you must turn this option on, as the libc functions are incapable of accessing these databases from inside of a chroot(). At configure-time, the configuration script will attempt to detect whether or not you need this support, and make it the default. However, such "guessing" may fail, and you will have to manually enable or disable the feature. If you cannot see user or group names when performing a directory listing inside an anonymous chrooted login, this indicates you must enable the directive. Use of the AuthUserFile or AuthGroupFile directives will force partial support for persistent user or group database files, regardless of PersistentPasswd's setting.

Note: NIS/NIS+ and NSS users will most likely want to disable this feature, regardless of proftpd's detected configuration defaults. Failure to disable this will make your NIS/NIS+ maps and NSS lookups not work! On certain systems, you may also need to compile ProFTPD with the --enable-autoshadow option in order to authenticate both users from NIS maps or NSS lookups, and local users.

See also

Examples

Description

The PidFile directive sets the file to which the server records the process id of the daemon. The filename should be relative to the system root, ie /var/run/proftpd/pidfile. The PidFile is only used in standalone mode. It is often useful to be able to send the server a signal, so that it closes and then reopens its ErrorLog and TransferLog, and re-reads its configuration files. This is done by sending a SIGHUP (kill -1) signal to the process id of the master daemon listed in the PidFile.

See also

Examples

Description

The Port directive configures the TCP port which proftpd will listen on while running in standalone mode. It has no effect when used upon a server running in inetd mode (see ServerType). The directive can be used in conjunction with <VirtualHost> in order to run a virtual server on the same IP address as the master server, but listening on a different port.

For any server, either <VirtualHost> or server config, setting Port 0 effectively turns off that server.

See also

Examples

Description

The RadiusAcctServer is used to specify a RADIUS server to be used for accounting. The server parameter may be either an IP address or a DNS hostname. If not specified, the port used will be the IANA-registered 1813. The optional timeout parameter is used to tell mod_radius how long to wait for a response from the server; it defaults to 30 seconds.

Multiple RadiusAcctServers may be configured; each will be tried, in order of appearance in the configuration file, until that server times out or mod_radius receives a response.

If no RadiusAcctServers are configured, mod_radius will not use RADIUS for accounting.

See also

RadiusAuthServer

Description

The RadiusAcctServer is used to specify a RADIUS server to be used for accounting. The server parameter may be either an IP address or a DNS hostname. If not specified, the port used will be the IANA-registered 1813. The optional timeout parameter is used to tell mod_radius how long to wait for a response from the server; it defaults to 30 seconds.

Multiple RadiusAcctServers may be configured; each will be tried, in order of appearance in the configuration file, until that server times out or mod_radius receives a response.

If no RadiusAcctServers are configured, mod_radius will not use RADIUS for accounting.

See also

RadiusAuthServer

Description

The RadiusEngine directive enables or disables the module's runtime RADIUS engine. If it is set to off this module does no RADIUS authentication or accounting at all. Use this directive to disable the module instead of commenting out all mod_radius directives.

See also

Description

The RadiusLog directive is used to a specify a log file for mod_radius reporting and debugging, and can be done a per-server basis. The file parameter must be the full path to the file to use for logging. Note that this path must not be to a world-writeable directory and, unless AllowLogSymlinks is explicitly set to on (generally a bad idea), the path must not be a symbolic link.

If file is "none", no logging will be done at all; this setting can be used to override a RadiusLog setting inherited from a <Global> context.

See also

Description

The RadiusRealm directive configures a realm string that will be added to the username in the constructed RADIUS packets.

See also

Examples

  RadiusRealm .castaglia.org

Description

The RadiusUserInfo directive is used to configure login information used for every user authenticated via RADIUS. The optional suppl-group-names and suppl-group-ids parameters are used to specify supplemental group membership for each user; the number of names and IDs must match if these parameters are used.

In order to support RADIUS servers that may use custom attributes in their Access-Accept response packets to supply user information back to the RADIUS client (mod_radius in this case), this directive allows the following syntax for some of its parameters:

  $(attribute-id:default-value)

where the enclosing $() signals that the parameter is to be supplied by the RADIUS server, attribute-id is the custom attribute ID for which to search in the response packet, and default-value is the value to use in case the requested attribute is not present in the response packet. This syntax is not supported for the suppl-group-names or suppl-group-ids parameters.

If RadiusUserInfo is not used, mod_radius will perform pure "yes/no" authentication only, in the style of PAM. The information that would have been configured via this directive will be pulled from other sources (e.g. /etc/passwd, AuthUserFiles, MySQL tables, etc).

See also

Description

The RatioFile directive .... Example: RatioFile

See also

Examples

Description

The Ratios directive .... Example: Ratios

See also

Examples

Description

The RatioTempFile directive .... Example: RatioTempFile

See also

Examples

Description

The RequireValidShell directive configures the server, virtual host or anonymous login to allow or deny logins which do not have a shell binary listed in /etc/shells. By default, proftpd disallows logins if the user's default shell is not listed in /etc/shells. If /etc/shells cannot be found, all default shells are assumed to be valid.

See also

Examples

Description

The RewriteCondition directive defines a rule condition. Precede a RewriteRule directive with one or more RewriteCondition directives. The following rewriting rule is only used if its pattern matches the current state of the FTP command and if these additional conditions apply too.

Condition is a string which can contain the following expanded constructs in addition to plain text:

• RewriteRule backreferences

  These are backreferences of the form:

  $N

  (0 <= N <= 9) which provide access to the grouped parts (parentheses!) of the pattern from the corresponding RewriteRule directive (the one following the current bunch of RewriteCondition directives). Note that $0 will refer back to the entire original string being matched.

• RewriteCondition backreferences

  These are backreferences of the form:

  %N

  (0 <= N <= 9) which provide access to the grouped parts (parentheses!) of the pattern from the previous RewriteCondition attached to this RewriteRule.

• RewriteMap expansions:

  These are expansions of the form:

  ${map-name:lookup-key|default-value}

  See the documentation for RewriteMap for more details.

• Variable substitutions:

  These are substitutions of the form:

  • %a client IP address

  • %c name of Class for current session

  • %f filename

  • %F transfer path, as seen by the client (only useful for upload/download commands)

  • %g primary group of authenticated user

  • %G supplemental groups of authenticated user

  • %h client DNS name

  • %m FTP command

  • %p port of server handling the session

  • %u name of authenticated user

  • %U name of user sent by client via USER

  • %v ServerName of server handling the session

Pattern is the condition pattern, i.e., a regular expression which is applied to the current instance of the condition, i.e., condition is evaluated and then matched against pattern. You can prefix the pattern string with a '!' character (exclamation mark) to specify a non-matching pattern.

See also

RewriteRule RewriteMap

Examples

Description

The RewriteEngine directive enables or disables the module's runtime rewriting engine. If it is set to off this module does no parsing or rewriting at all. Use this directive to disable the module instead of commenting out all mod_rewrite directives.

See also

Description

The RewriteLock directive sets the filename for a synchronization lockfile which mod_rewrite needs to communicate with RewriteMaps of type fifo. Set file to a local absolute path (not on a NFS-mounted device) when you want to use a rewriting FIFO. It is not required for other types of rewriting maps.

See also

Description

The RewriteLog directive is used to a specify a log file for mod_rewrite reporting and debugging, and can be done a per-server basis. The file parameter must be the full path to the file to use for logging. Note that this path must not be to a world-writeable directory and, unless AllowLogSymlinks is explicitly set to on (generally a bad idea), the path must not be a symbolic link. In general, this directive should only be used for debugging your mod_rewrite configuration, and should be removed once debugging is completed; do not use this directive in a production configuration.

If file is "none", no logging will be done at all; this setting can be used to override a RewriteLog setting inherited from a <Global> context.

See also

Description

The RewriteMap directive defines a rewriting map which can be used inside rule substitution strings by the mapping-functions to insert/substitute fields through a key lookup. The source of this lookup can be of various types.

The map-name is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via one of the following constructs:

${ map-name : lookup-key }

${ map-name : lookup-key | default-value

When such a construct occurs the map map-name is consulted and the key lookup-key is resolved. If the key is found, the map-function construct is substituted by subst-value. If the key is not found then it is substituted by default-value or by the empty string if no default-value was specified.

The following combinations for map-type and map-src can be used:

• Standard Plain Text

  map-type: txt, map-src: Unix filesystem path to valid regular file.

  This is the standard rewriting map feature where the map-src is a plain ASCII file containing either blank lines, comment lines (starting with a '#' character) or pairs like the following - one per line.

  matching-key subst-value

  Example 1-1. Example Usermap

  		    # --------------------------------------------
      		    # usermap.txt -- map for rewriting user names
      		    # --------------------------------------------
  
      		    Dave.Admin      dave       # The Uber-admin
      		    root            anonymous  # no one should be logging in as root anyway
  		

  And, to configure this map to be used:

  			RewriteMap real-to-user txt:/path/to/file/usermap.txt
  		

• FIFO/Named Pipe

  map-type: fifo, map-src: Unix filesystem path to valid FIFO.

  For this rewriting map, map-src is a FIFO (a.k.a. named pipe). To create it, you can use the mkfifo(1) command. An external program that opens the FIFO for reading and writing must be started before proftpd is started. This program can communicate with the rewriting engine via the FIFO. For each mapping lookup, it can read the key to lookup as a newline-terminated string from the FIFO. It then has to write back to the FIFO the looked-up value as a newline-terminated string, or just simply newline character (denoting an empty string) if there is no corresponding value for the given key).

  An example program which will implement a 1:1 mapping (i.e., key == value) could be:

  Example 1-2. Example FIFO/Named Pipe 1:1 mapping

  #!/usr/bin/perl
      use strict;
  
      use File::Basename qw(basename);
      use Getopt::Long;
      use IO::Handle;
      use IO::Select;
  
      my $default_delay = 0.5;
      my $program = basename($0);
      my %opts = ();
  
      GetOptions(\%opts, 'delay=f', 'fifo=s', 'help', 'verbose');
  
      usage() if $opts{'help'};
  
      my $delay = $opts{'delay'} ? $opts{'delay'} : $default_delay;
  
      die "$program: missing required --fifo parameter\n" unless $opts{'fifo'};
      my $fifo = $opts{'fifo'};
  
      my $verbose = $opts{'verbose'} ? 1 : 0;
  
      open(my $fifo_fh, "+> $fifo") or die "$program: unable to open $fifo: $!\n";
  
      # Instantiate a Select object for knowing when to read from and write to
      # the FIFO.
      my $sel = IO::Select->new();
  
      while (1) {
  
        # Blocking select() for reading.
        $sel->add($fifo_fh);
  
        print STDERR "$program: selecting for reading\n" if $verbose;
        my ($rfh) = $sel->can_read();
  
        my $key = <$rfh>;
        print STDERR "$program: read '$key'\n" if $verbose;
  
        # Lookup a value for the given key.
        my $value = lookup_value($key);
  
        # Clear the Select object's filehandles.
        $sel->remove();
  
        print $fifo_fh "$value\n" if $verbose;
        $fifo_fh->flush();
  
        print STDERR "$program: wrote '$value'\n" if $verbose;
  
        # Wait for the buffer's byte to be cleared before reading again.
        wait_fifo($fifo_fh);
      }
  
      close($fifo_fh);
      print STDOUT "$program: done\n" if $verbose;
  
      exit 0;
  
      # --------------------------------------------------------------------------
      sub lookup_value {
        my ($key) = @_;
  
        # NOTE: do something to obtain a value for the given key here.
        chomp(my $value = $key);
  
        return $value;
      }
  
      # --------------------------------------------------------------------------
      sub usage {
        print STDOUT <<END_OF_USAGE;
  
      usage: $program [options]
  
        --delay         Configure the buffer check delay.
                        The default is $default_delay seconds.
  
        --fifo          Configure the path to the FIFO.  Required.
  
        --help          Displays this message.
  
        --verbose       Enables verbose output while $program runs.
  
      END_OF_USAGE
  
        exit 0;
      }
  
      # --------------------------------------------------------------------------
      sub wait_fifo {
        my ($fh) = @_;
  
        # Now we get tricky.  Use ioctl(2) to poll the number of bytes to
        # be read from the FIFO filehandle.  When the number drops to zero,
        # it means that the data we just wrote has been read from the buffer
        # by some other process, so we can go back to the top of this loop.
        # Otherwise, if this program loops faster than the reader/writer on
        # the other end of the FIFO, we'd end up reading the data we just
        # wrote.  Quite annoying, actually.
        #
        # Note: this value must be manually extracted from the system header files
        # using the following program:
        #
        # -------- fionread.c -------------------
        #  #include <sys/ioctl.h>
        #
        #  int main(int argc, char *argv[]) {
        #   printf("%#08x\n", FIONREAD);
        #   return 0;
        # }
        # ---------------------------------------
        #
        # > cc -o fionread fionread.c
        # > ./fionread
  
        my $FIONREAD = 0x00541b;
  
        my $size = pack('L', 0);
        ioctl($fh, $FIONREAD, $size) or die "$program: unable to use ioctl: $!\n";
        $size = unpack('L', $size);
  
        while ($size != 0) {
          print STDERR "$program: waiting for buffer to be read\n" if $verbose;
          select(undef, undef, undef, $delay);
  
          $size = pack('L', 0);
          ioctl($fh, $FIONREAD, $size) or die "$program: unable to use ioctl: $!\n";
          $size = unpack('L', $size);
        }
      }
  
  		

  To make use of this example script, simply implement your lookup code in the lookup_value() subroutine. Be very careful with such scripts, though:

  1. "Keep it simple, stupid" (KISS), because if this program hangs it will hang proftpd when the rule occurs. Well, keep it as simple as possible...

  2. Avoid one common mistake: avoid buffered I/O if possible. This can cause a deadloop. If necessary, be sure to flush the filehandle before reading, and after writing.

  3. Use the RewriteLock directive to define a lockfile mod_rewrite can use to synchronize the communication to the FIFO program. By default no such synchronization takes place.

• Internal Function

  map-type: int, map-src: Internal mod_rewrite function.

  Here the map-src is a mod_rewrite built-in function. Currently you cannot create your own, but the following functions already exist:

  • toupper

    Converts the looked up key to all upper case.

  • tolower

    Converts the looked up key to all lower case.

  • unescape

    Translates hex-encodings in the looked up key back to special characters.

  • utf8trans

    Translates UTF-8 encodings in the lookup up key into Latin-1 characters.

The RewriteMap directive can occur more than once. For each mapping-function use one RewriteMap directive to declare its rewriting map name.

Note: For plain text files the looked-up keys are cached in-core until the mtime of the text map file changes or the server does a restart. This way you can have map-functions in rules which are used for every request. This is no problem, because the parsing of the text files only happens once!

See also

RewriteCondition

Description

The RewriteRule directive is the real rewriting workhorse. The configuration directive can occur more than once. Each directive defines a single rewriting rule. The order of definition of these rules is important, because this order is used when applying the rules at run-time.

Pattern can be POSIX regular expression which gets applied to the current FTP command argument(s).

Some hints about the syntax of regular expressions:

• Text:

  	        .           Any single character
    		[chars]     Character class: one of chars
  		[^chars]    Character class: none of chars
    		text1|text2 Alternative: text1 or text2
  	      

• Quantifiers:

  	        ?           0 or 1 of the preceding text
    		*           0 or N of the preceding text (N > 0)
    		+           1 or N of the preceding text (N > 1)
  	      

• Grouping:

   	      (text)       Grouping of text
                		   (either to set the borders of an alternative or
                		   for making backreferences where the Nth group can 
                		   be used on the RHS of a RewriteRule with $N)
  	      

• Anchors:

  	        ^           Start of line anchor
    		$           End of line anchor
  	      

• Escaping:

  		\char       Escape that particular char
                		    (for instance to specify the chars ".[]()" etc.)
  	      

For more information about regular expressions have a look at your local regex(3) manpage. If you are interested in more detailed information about regular expressions and their variants (POSIX regex, Perl regex, etc.) have a look at the following dedicated book on this topic:

Mastering Regular Expressions Jeffrey E.F. Friedl Nutshell Handbook Series O'Reilly & Associates, Inc. 1997 ISBN 1-56592-257-3

Additionally in mod_rewrite the NOT character ('!') is a possible pattern prefix. This gives you the ability to negate a pattern; to say, for instance: "if the current argument(s) does NOT match this pattern". This can be used for exceptional cases, where it is easier to match the negative pattern, or as a last default rule.

Notice: When using the NOT character to negate a pattern you cannot have grouped wildcard parts in the pattern. This is impossible because when the pattern does NOT match, there are no contents for the groups. In consequence, if negated patterns are used, you cannot use $N in the substitution string.

Substitution of a rewriting rule is the string which is substituted for (or replaces) the original argument(s) for which pattern matched. Beside plain text you can use:

1. $N backreferences to the RewriteRule pattern

2. %N backreferences to the last matched RewriteCondition pattern

3. variables as in RewriteCondition test strings

4. map function calls (${map-name:lookup-key|default-value})

Backreferences are $N (N=0..9) identifiers which will be replaced by the contents of the Nth group of the matched pattern. The variables are the same as for the condition of a RewriteCondition directive, with two additions:

• %P process ID

• %t Unix time since the epoch, in seconds

The map functions come from the RewriteMap directive and are explained there. These four types of variables are expanded in the order of the above list.

All of the rewriting rules are applied to substitution. The command argument(s) is completely replaced by the substitution.

See also

RewriteCondition RewriteMap

Examples

Description

RLimitCPU takes from one to three parameters. The first parameter may be one of "daemon" (applies the limit only to the daemon process), "session" (applies the limit only to child processes handling each FTP session), or "none" (disables any possibly inherited limits). Note that if "daemon" is used, the directive may then only occur in the "server config" context. If none of these keywords are used, the limit is assumed to apply to both daemon and session processes. After any potential keyword, the resource limit must be set. The next parameter is also optional, and sets the maximum resource limit. Either limit parameter can be a number, or "max" to indicate to the server that the limit should be set to the maximum allowed by the operating system.

CPU resource limits are expressed in seconds per process.

See Also:

RLimitMemory, RLimitOpenFiles

Examples

Description

RLimitMemory takes from one to three parameters. The first parameter may be one of "daemon" (applies the limit only to the daemon process), "session" (applies the limit only to child processes handling each FTP session), or "none" (disables any possibly inherited limits). Note that if "daemon" is used, the directive may then only occur in the "server config" context. If none of these keywords are used, the limit is assumed to apply to both daemon and session processes. After any potential keyword, the resource limit must be set. The next parameter is also optional, and sets the maximum resource limit. Either limit parameter can be a number, or "max" to indicate to the server that the limit should be set to the maximum allowed by the operating system.

Memory resource limits are expressed in bytes per process. An optional case-insensitive units specifier may follow the number of bytes given: G (Gigabytes), M (Megabytes), K (Kilobytes), or B (bytes). If the units specifier is used, the given number of bytes is multiplied by the appropriate factor.

See Also

RLimitCPU, RLimitOpenFiles

Description

RLimitOpenFiles takes from one to three parameters. The first parameter may be one of "daemon" (applies the limit only to the daemon process), "session" (applies the limit only to child processes handling each FTP session), or "none" (disables any possibly inherited limits). Note that if "daemon" is used, the directive may then only occur in the "server config" context. If none of these keywords are used, the limit is assumed to apply to both daemon and session processes. After any potential keyword, the resource limit must be set. The next parameter is also optional, and sets the maximum resource limit. Either limit parameter can be a number, or "max" to indicate to the server that the limit should be set to the maximum allowed by the operating system.

File resource limits are expressed in number of files per process.

See Also:

RLimitCPU, RLimitMemory

Description

Normally, proftpd disallows root logins under any circumstance. If a client attempts to login as root, using the correct password, a special security message is sent to syslog. When the RootLogin directive is turned On, the root user may authenticate just as any other user could (assuming no other access control measures deny access); however the root login security message is still sysloged. Obviously, extreme care should be taken when using this directive.

The use of RootLogin in the Anonymous context is only valid when the User / Group defined in the Anonymous block is set to 'root'

See also

Examples

Description

The RootRevoke directive causes all root privileges to be dropped once a user is authenticated. This will also cause active transfers to be disabled, if the server is listening on a port less than 1025. Note that this only affects active transfers; passive transfers will not be blocked.

See also

Examples

Description

The SaveRatios directive .... Example: SaveRatios

See also

Examples