Proftpd configuration directives

Configuration Directives
The following configuration parameters control ProFTPD features and configuration: AccessGrantMsg Allow AllowAll AllowGroup AllowOverwrite AllowRetrieveRestart AllowStoreRestart AnonRequirePassword <Anonymous> AnonymousGroup AuthAliasOnly AuthGroupFile AuthUserFile Bind DefaultRoot DefaultServer DeferWelcome Deny DenyAll DenyGroup <Directory> DirFakeGroup DirFakeMode DirFakeUser DisplayFirstChdir DisplayLogin Group GroupOwner GroupPassword HideGroup HideNoAccess HideUser IdentLookups IgnoreHidden <Limit> LsDefaultOptions MaxClients MaxLoginAttempts Order PersistentPasswd Port RequireValidShell RootLogin ServerAdmin ServerName ServerType ShowSymlinks SocketBindTight SyslogFacility tcpBackLog tcpReceiveWindow tcpSendWindow TimeoutIdle TimeoutLogin TimeoutNoTransfer Umask UseFtpUsers User UserAlias UserPassword <VirtualHost> AccessGrantMsg
Syntax: AccessGrantMsg message
Default: Dependent on login type
Context: server config, <VirtualHost>, <Anonymous>
Compatibility: 0.99.0pl5 and later
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.
Example:
AccessGrantMsg "Guest access granted for %u." Syntax: Allow ["from"] "all"|"none"|host|network[,host|network[,.]]
Default: Allow from all
Context: <Limit>
Compatibility: 0.99.0pl6 and later
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
conjuction 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 address
which specify an entire network should begin with a trailing period (i.e. .proftpd.org for the entire
proftpd.org domain).
<Limit LOGIN>Order Allow,DenyAllow from 128.44.26.,128.44.26.,myhost.mydomain.edu,.trusted-domain.orgDeny from all</Limit> AllowAll
Syntax: AllowAll
Default: Default is to implicitly AllowAll, but not explicitly
Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
Compatibility: 0.99.0 and later
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.
AllowGroup
Syntax: AllowGroup group-expression
Default: None
Context: <Limit>
Compatibility: 1.1.1 and later
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 seperated list of groups or "not" groups (by prefixing a group
name with the ‘!’ character) that are to be allowed access to the block. The expression is parsed as a
boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in
order for the explicit allow to apply.
AllowOverwrite
Syntax: AllowOverwrite on|off
Default: AllowOverwrite off
Context: server config, <VirtualHost>, <Anonymous>, <Directory>, .ftpaccess
Compatibility: 0.99.0 and later
The AllowOverwrite directive permits newly transfered files to overwrite existing files. By default,ftp clients cannot overwrite existing files.
AnonRequirePassword
Syntax: AnonRequirePassword on|off
Default: AnonRequirePassword off
Context: <Anonymous>
Compatibility: 0.99.0 and later
Normally, anonymous FTP logins do not require the client to authenticate themselves via thenormal method of a transmitted cleartext password which is hashed and matched against an existingsystem user’s password. Instead, anonymous logins are expected to enter their e-mail address whenprompted for a password. Enabling the AnonRequirePassword directive requires anonymous loginsto enter a valid password which must match the password of the user that the anonymous daemonruns as. This can be used to create "guest" accounts, which function exactly as normal anonymouslogins do (and thus present a "chrooted" protected file system to the client), but require a validpassword on the server’s host system.
Example of a "guest" account configuration: <Anonymous ~roger>User rogerGroup otherUserAlias proftpd rogerAnonRequirePassword on# Deny write operations to all directories, underneath root-dir# Default is to allow, so we don’t need a <Limit> for read operations.
<Directory *><Limit WRITE>DenyAll</Limit></Directory># Deny all read/write operations in incoming. Because these arecommand-group# limits, we can explicitly permit certain operations which will takeprecedance# over our group limit.
<Directory incoming><Limit READ WRITE>DenyAll</Limit># The only command allowed in incoming is STOR (transfer file from client to server)<Limit STOR>AllowAll</Limit></Directory></Anonymous> AllowRetrieveRestart
Syntax: AllowRetrieveRestart on|off
Default: AllowRetrieveRestart on
Context: server config, <VirtualHost>, <Anonymous>, <Directory>, .ftpaccess
Compatibility: 0.99.0 and later
The AllowRetrieveRestart directive permits or denies clients from performing "restart" retrieve filetransfers via the FTP REST command. By default this is enabled, so that clients may resumeinterrupted file transfers at a later time without losing previously collected data.
AllowStoreRestart
Syntax: AllowStoreRestart on|off
Default: AllowStoreRestart off
Context: server config, <VirtualHost>, <Anonymous>, <Directory>, .ftpaccess
Compatibility: 0.99.0 and later
The AllowStoreRestart directive permits or denies clients from "restarting" interrupted store filetransfers (those sent from client to server). By default restarting (via the REST command) is notpermitted 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 ofpreviously stored files (even if not their own).
<Anonymous>
Syntax: <Anonymous root-directory>
Default: Not applicable
Context: server config,<VirtualHost>
Compatibility: 0.99.0 and later
The Anonymous configuration block is used to create an anonymous FTP login, and is terminatedby a matching </Anonymous> directive. The root-directory parameters specifies which directorythe daemon will first chdir to, and then chroot, immediately after login. Once the chroot operationsuccessfully completes, higher level directories are no longer accessible to the running childdaemon (and thus the logged in user). By default, proftpd assumes an anonymous login if theremote client attempts to login as the currently running user; unless the current user is root, inwhich 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 Userand 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 toenter a valid e-mail address in place of a normal password (which is logged). If this behavior isundesirable for a given <Anonymous> configuration block, it can be overridden via theAnonRequirePassword 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.
Example of a typical anonymous FTP configuration: <Anonymous /home/ftp>User ftp # After anonymous login, daemon runs as user ftp.
Group ftp # After anonymous login, daemon runs as group ftp.
UserAlias anonymous ftp # Client login as ’anonymous’ is aliased to’ftp’.
# Deny write operations to all directories, underneath root-dir# Default is to allow, so we don’t need a <Limit> for read operations.
<Directory *><Limit WRITE>DenyAll</Limit></Directory><Directory incoming><Limit READ WRITE>DenyAll</Limit><Limit STOR>AllowAll</Limit></Directory></Anonymous> AnonymousGroup
Syntax: AnonymousGroup group-expression
Default: None
Context: server config,<VirtualHost>
Compatibility: 1.1.3 and later
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 isrequired, and a special dynamic anonymous configuration is created, with the user’s home directoryas the default root directory. If a DefaultRoot directive also applies to the user, this directory is used 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.
AuthAliasOnly
Syntax: AuthAliasOnly on|off
Default: AuthAliasOnly off
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 1.1.3 and later
AuthAliasOnly restricts authenication 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.
AuthGroupFile
Syntax: AuthGroupFile path
Default: None
Context: server config,<VirtualHost>
Compatibility: 1.0.3/1.1.1 and later
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 conjuction with AuthUserFile).
Note that this file need not reside inside a chroot()ed directory structure for Anonymous or
DefaultRoot logins, as it is help open for the duration of client connections.
AuthUserFile
Syntax: AuthUserFile path
Default: None
Context: server config,<VirtualHost>
Compatibility: 1.0.3/1.1.1 and later
AuthUserFile specifies an alternate passwd file, having the same format as the system /etc/passwdfile, 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 conjuction with AuthGroupFile).
Note that this file need not reside inside a chroot()ed directory structure for Anonymous or
DefaultRoot logins, as it is help open for the duration of client connections.
Syntax: Bind address
Default: none
Context: server config,<VirtualHost>
Compatibility: 1.1.6 and later
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.
DefaultRoot
Syntax: DefaultRoot directory [group-expression]
Default: DefaultRoot /
Context: server config,<VirtualHost>
Compatibility: 0.99.0pl7 and later
The DefaultRoot directive controls the default root directory assigned to a user upon login. IfDefaultRoot is set to a directory other than "/", a chroot operation is performed immediately after aclient authenticates. This can be used to effectively isolate the client from a portion of the hostsystem 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. If the DefaultRoot directivespecifies a directory which disallows access to the logged-in user’s home directory, the user’scurrent working directory after login is set to the DefaultRoot instead of their normal homedirectory. 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 afterlogin. 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 forimplementing general system security as there are potentially ways that a user can "escape" the jail.
ServerName "A test ProFTPD Server"ServerType inetdUser ftpGroup ftp## This causes proftpd to perform a chroot into the authenticatinguser’s directory immediately after login.
# Once this happens, the user is unable to "see" higher leveldirectories.
# Because a group-expression is included, only users who are a memberof# the group ’users’ and NOT a member of ’staff’ will have theirdefault# root directory set to ’~’.
DefaultRoot ~ users,!staff. DefaultServer
Syntax: DefaultServer on|off
Default: DefaultServer off
Context: server config,<VirtualHost>
Compatibility: 0.99.0pl6 and later
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.
DeferWelcome
Syntax: DeferWelcome on|off
Default: DeferWelcome off
Context: server config,<VirtualHost>
Compatibility: 0.99.0 and later
The DeferWelcome directive configures a master or virtual server to delay transmitting theServerName and address to new connections, until a client has successfully authenticated. Ifenabled, the initial welcome message will be exceedingly generic and will not give away any typeof information about the host that the daemon is actively running on. This can be used bysecurity-conscious administrators to limit the amount of "probing" possible from non-trusted Syntax: Deny ["from"] "all"|"none"|host|network[,host|network[,.]]
Default: Deny from none
Context: <Limit>
Compatibility: 0.99.0pl6 and later
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.
Syntax: DenyAll
Default: None
Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
Compatibility: 0.99.0 and later
The DenyAll directive is analogous to a combination of "order deny,allow <cr> deny from all",with the exception that it has a higher precendance when parsed. It is provided as a convenientmethod of completely denying access to a directory, anonymous ftp or limit block. Because of it’sprecedance, it should not be intermixed with normal Order/Deny directives. The DenyAll directivecan be overridden at a lower level directory by using AllowAll. DenyAll and AllowAll are mutuallyexclusive.
DenyGroup
Syntax: DenyGroup group-expression
Default: None
Context: <Limit>
Compatibility: 1.1.1 and later
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 seperated list of groups or "not" groups (by prefixing a group
name with the ‘!’ character) that are to be denied access to the block. The expression is parsed as a
boolean "and" list, meaning that ALL elements of the expression must evaluate to logically true in
order for the explicit deny to apply.
<Directory>
Syntax: <Directory pathname>
Default: Not applicable.
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0 and later
This directive creates a block of configuration directives which applies only to the specifieddirectory and it’s sub-directories. The block is ended with </Directory>. Per-directory configurationis enabled during run-time with a "closest" match algorithm, meaning that the <Directory> directivewith 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> isencountered, at which time the original per-directory configuration is replaced with the closermatch. Note that this does not apply to <Limit> </Limit> blocks, which are inherited by allsub-directories until a <Limit> block is reached in a closer match.
Example:<Directory /users/robroy/private>HideNoAccess</Directory> A trailing slash and wildcard ("/*") can be appended to the directory, specifying that theconfiguration 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> configurationblocks. <Directory> blocks cannot be nested (they are automatically nested at run-time based ontheir pathnames). Pathnames must always be absolute (except inside <Anonymous>), and shouldnot reference symbolic links. Pathnames inside an <Anonymous> block can be relative, indicatingthat 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 defered mode. When in defered mode, the directory context is not
hashed and sorted into the configuration tree at boot time, but rather this hashing is defered 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.
Example:<Directory ~/anon-ftp><Limit WRITE>DenyAll</Limit READ></Directory> DirFakeGroup
Syntax: DirFakeGroup On|Off [groupname]
Default: DirFakeGroup Off
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 1.1.5
DirFakeGroup and it’s companion directive, DirFakeUser, can be used to hide the true group and
user owners of files 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’. Both DirFakeGroup and DirFakeUser are completely cosmetic;
the groupname or username specified need not exists on the system, and neither directive
affects permissions, real ownership or access control in any way.
DirFakeMode
Syntax: DirFakeMode octal-mode
Default: none
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 1.1.6
The DirFakeMode directive configures a mode (or permissions) which will be displayed for ALLfiles 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 thisdirective. For example: -rw-r----- . arbitrary.filedrwxr-x--- . arbitrary.directory As with DirFakeUser, and DirFakeGroup, the "fake" permissions shown in directory listings arecosmetic only, they do not affect real permissions or access control in any way.
DirFakeUser
Syntax: DirFakeUser On|Off [username]
Default: DirFakeUser Off
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 1.1.5
DisplayFirstChdir
Syntax: DisplayFirstChdir filename
Default: None
Context: server config,<VirtualHost>, <Anonymous>, <Directory>
Compatibility: 0.99.0 and later, magic cookies only in 0.99.0pl10 and later
The DisplayFirstChdir directive configures an ascii text filename which will be displayed to theuser the first time they change into a directory (via CWD) per a given session. The file will also bedisplayed if proftpd detects that it’s last modification time has changed since the previoius CWDinto a given directory. If the filename is relative, it is looked for in the new directory that the userhas changed into. Note that for anonymous ftp logins (see <Anonymous>), the file must resideinside the chroot()ed file system space. If the file cannot be found or accessed, no error occurs andnothing is logged or displayed to the client.
Both DisplayFirstChdir and DisplayLogin 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.
%T Current
DisplayLogin
Syntax: DisplayLogin filename
Default: None
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0 and later
The DisplayLogin directive configures an ascii text filename which will be displayed to the userwhen they initially login. The filename can be either relative or absolute. In the case of a relativefilename, 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 thatfor anonymous logins, the file must reside inside the chroot()ed file system space. If the file cannotbe found or accessed, no error occurs and nothing is logged or displayed to the client.
DisplayLogin supports the same "magic cookies" as DisplayFirstChdir.
Syntax: Group groupid
Default: None
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0 and later
The Group directive configures which group the server daemon will normally run at. See User formore details.
GroupOwner
Syntax: GroupOwner groupid
Default: GroupOwner current-group
Context: server config,<VirtualHost>, <Directory>, <Anonymous>, .ftpaccess
Compatibility: 0.99.0 and later
The GroupOwner directive configures which group all newly created directories and files will beowned by, within the context that GroupOwner is applied to. Note that GroupOwner cannot be usedto override the host OS/file system user/group paradigm. If the current user is not a member of thespecified group, new files and directories will not be able to be chown()ed to the GroupOwnergroup. If this happens, file STOR (send file from client to server) and MKD (mkdir) operations willsucceed normally, however the new directory entries will be owned by the current user’s defaultgroup (a warning message is also logged) instead of by the desired group.
GroupPassword
Syntax: GroupPassword groupid hashed-password
Default: None
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0pl5 and later
The GroupPassword directive creates a special "group" password which allows all users in the
specified group to authenticate using a single password. The group/password supplied is only
effective inside the context to which GroupPassword is applied. The hashed-password argument is
a standard cleartext password which has been passed through the standard unix crypt() library
function. Extreme care should be taken when using GroupPassword, as serious security
problems may arise if group membership is not carefully controlled.
HideGroup
Syntax: HideGroup groupid
Default: None
Context: <Directory>, <Anonymous>
Compatibility: 0.99.0 and later
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: HideUser, HideNoAccess, IgnoreHidden HideNoAccess
Syntax: HideNoAccess
Default: None
Context: <Directory>,<Anonymous>
Compatibility: 0.99.0 and later
The HideNoAccess directive configures a <Directory> or <Anonymous> block to hide all directoryentries in a directory listing (via the LIST or NLST FTP commands) to which the current logged-in,authenticated user has no access to. Normal Unix-style permissions always apply, so that although auser may not be able to see a directory entry that has HideNoAccess applied, they will receive anormal "Permission denied" error message when attempting to blindly manipulate the file systemobject. The directory or file can be made completely invisible to all FTP commands by applyingIgnoreHidden in conjunction with HideNoAccess.
See also: HideUser, HideGroup, IgnoreHidden HideUser
Syntax: HideUser userid
Default: None
Context: <Directory>, <Anonymous>
Compatibility: 0.99.0 and later
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 IdentLookups
Syntax: IdentLookups on|off
Default: IdentLookups on
Context: server config
Compatibility: 1.1.5 and later
Normally, when a client initially connects to proftpd, the ident protocol (RFC1413) is used toattempt to identify the remote username. This can be controlled via the IdentLookups directive.
IgnoreHidden
Syntax: IgnoreHidden on|off
Default: IgnoreHidden off
Context: <Limit>
Compatibility: 0.99.0 and later
Normally, files hidden via HideNoAccess, HideUser or HideGroup can be operated on by all FTPcommands (assuming Unix file permissions allow access), even though they do not appear indirectory listings. Additionally, even when normal file system permissions disallow access, proftpdreturns 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 anyhidden directory entries for the set of limited FTP commands. This has the effect of returning anerror similar to "No such file or directory" when the client attempts to use the limited commandupon a hidden directory or file.
<Limit>
Syntax: <Limit command|command-group [command2 .]>
Default: None
Context: server config, <VirtualHost>, <Directory>, <Anonymous>
Compatibility: 0.99.0 and later
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. Note that limits placed on this command also apply
to the CDUP command (Change Directory UP).
MKD (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 (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 addtion, 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). i.e. RETR,
STAT, etc.
WRITE
All FTP commands which deal with file or directory write/creation/deletion (MKD and RMD
included).
DIRS
All FTP commands which deal with directory listing. i.e LIST and NLST.
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. Whilelimits can be used to restrict a command on a certain directory, they cannot be used to override thefile permissions inherent to the base operating/file system.
LsDefaultOptions
Syntax: LsDefaultOptions "options string"
Default: None
Context: server config, <VirtualHost>
Compatibility: 1.1.6 and later
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. Using the LsDefaultOptions directive can alter the default behavior of such listings,
but implying that a certain option (or options) is always present. For example, to force all directory
listings to always display ".dotfiles", one might:
MaxClients
Syntax: MaxClients numbers|none message
Default: MaxClients none
Context: server config, <Anonymous>, <VirtualHost>
Compatibility: 0.99.0 and later
The MaxClients directive configures the maximum number of authenticated clients which may belogged into a server or anonymous account. Once this limit is reached, additional clients attemptingto 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.
MaxClients 5 "Sorry, the maximum number of allowed users are already connected(%m)" 530 Sorry, the maximum number of allowed users are already connected (5) MaxLoginAttempts
Syntax: MaxLoginAttempts number
Default: MaxLoginAttempts 3
Context: server config,<VirtualHost>
Compatibility: 0.99.0 and later
The MaxLoginAttempts directive configures the maximum number of times a client may attempt toauthenticate to the server during a given connection. After the number of attempts exceeds thisvalue, the user is disconnected and an appropriate message is logged via the syslog mechanism.
Syntax: Order allow,deny|deny,allow
Default: Order allow,deny
Context: <Limit>
Compatibility: 0.99.0pl6 and later
The Order directive configures the order in which Allow and Deny directives are checked inside ofa <Limit> block. Because Allow directives are permissive, and Deny directives restrictive, theorder 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 permited; otherwise access is implicitly
denied.
For clarification, the following illustrates the steps used when checking Allow/Deny access: Order allow,deny
1. Check Allow directives. If one or more apply, exit with result: ALLOW
2. Check Deny directives. If one or more apply, exit with result: DENY
3. Exit with default implicit ALLOW
Order deny,allow
1. Check Deny directives. If one or more apply, exit with result: DENY
2. Check Allow directives. If one or more apply, exit with result: ALLOW
3. Exit with default implicit: DENY
PersistentPasswd
Syntax: PersistentPasswd on|off
Default: Platform dependent
Context: server config
Compatibility: 1.1.5 and later
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 achroot()ed login (note that /etc/shadow is never held open, for security reasons). On someplatforms, you must turn this option on, as the libc functions are incapable of accessing thesedatabases from inside of a chroot(). At configure-time, the configuration script will attempt todetect 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 groupnames when performing a directory listing inside an anonymous chrooted login, this indicates youmust enable the directive. Use of the AuthUserFile or AuthGroupFile directives will force partialsupport for persistent user or group database files; regardless of PersistentPasswd’s setting.
Note: NIS or NIS+ 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 not
work!
Syntax: Port port-number
Default: Port 21
Context: server config,<VirtualHost>
Compatibility: 0.99.0 and later
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 conjuction with <VirtualHost> in order to run a virtual server on the same
IP address as the master server, but listening on a different port.
RequireValidShell
Syntax: RequireValidShell on|off
Default: RequireValidShell on
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0 and later
The RequireValidShell directive configures the server, virtual host or anonymous login to allow ordeny logins which do not have a shell binary listed in /etc/shells. By defualt, proftpd disallowslogins if the user’s default shell is not listed in /etc/shells. If /etc/shells cannot be found, all defaultshells are assumed to be valid.
RootLogin
Syntax: RootLoginl on|off
Default: RootLogin off
Context: server config,<VirtualHost>
Compatibility: 1.1.5 and later
Normally, proftpd disallows root logins under any circumstance. If a client attempts to login asroot, using the correct password, a special security message is sent to syslog. When the RootLogindirective 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.
ServerAdmin
Syntax: ServerAdmin "admin-email-address"
Default: ServerAdmin root@localhost
Context: server config,<VirtualHost>
Compatibility: 0.99.0pl10 and later
The ServerAdmin directive sets the email address of the administrator for the server or virtualhost.
This address is displayed in magic cookie replacements (see DisplayLogin and DisplayFirstChdir).
ServerName
Syntax: ServerName "name"
Default: ServerName "ProFTPD Server 1.0"
Context: server config,<VirtualHost>
Compatibility: 0.99.0 and later
The ServerName directive configures the string that will be displayed to a user connecting to theserver (or virtual server if the directive is located in a <VirtualHost> block). See Also: <VirtualHost>
ServerType
Syntax: ServerType type-identifier
Default: ServerType standalone
Context: server config
Compatibility: 0.99.0 and later
The ServerType directive configures the server daemon’s operating mode. The type-identifier canbe one of two values: inetd
The daemon will expect to be run from the inetd "super server." New connections are passed
from inetd to proftpd and serviced immediately.
standalone
The daemon starts and begins listening to the configured port for incoming connections. New
connections result in spawned child processes dedicated to servicing all requests from the
newly connected client.
ShowSymlinks
Syntax: ShowSymlinks on|off
Default: (versions previous to 1.1.5) Off for anonymous logins, On for normal logins
Default: (versions 1.1.5 and beyond) ShowSymlinks On
Context: server config,<VirtualHost>,<Anonymous>
Compatibility: 0.99.0pl6 and later
Symbolic links (if supported on the host OS and filesystem) can be either shown in directorylistings (including the target of the link) or can be "hidden" (proftpd dereferences symlinks andreports the target’s permissions and ownership). The default behavior is to show all symbolic linkswhen normal users are logged in, and hide them for anonymous sessions. If a symbolic link cannotbe dereferenced for any reason (permissions, target does not exist, etc) and ShowSymlinks is off,proftpd displays the link as a directory entry of type ’l’ (link) with the ownership and permissionsof the actual link.
Under ProFTPD versions 1.1.5 and higher, the default behavior in regard to ShowSymlinks hasbeen changed so that symbolic links are always displayed as such (in all cases), unlessShowSymlinks off is explicitly set.
SocketBindTight
Syntax: SocketBindTight on|off
Default: SocketBindTight off
Context: server config
Compatibility: 0.99.0pl6 and later
The SocketBindTight directive controls how proftpd creates and binds it’s initial tcp listen sockets
in standalone mode (see ServerType). The directive has no effect upon servers running in inetd
mode, because listen sockets are not needed or created. When SocketBindTight is set to off (the
default), a single listening socket is created for each port that the server must listen on, regardless of
the number of IP addresses being used by <VirtualHost> configurations. This has the benefit of
typically requiring a relatively small number of file descriptors for the master daemon process, even
if a large number of virtual servers are configured. If SocketBindTight is set to on, a listen socket is
created and bound to a specific IP address for the master server and all configured virtual servers.
This allows for situations where an administrator may wish to have a particular port be used by both
proftpd (on one IP address) and another daemon (on a different IP address). The drawback is that
considerably more file descriptors will be required if a large number of virtual servers must be
supported.
Example: Two servers have been configured (one master and one virtual), with the IP addresses10.0.0.1 and 10.0.0.2, respectively. The 10.0.0.1 server runs on port 21, while 10.0.0.2 runs on port2001.
SocketBindTight off #default# proftpd creates two sockets, both bound to ALL available addresses.
# one socket listens on port 21, the other on 2001. Because each socket is # bound to all available addresses, no other daemon or user process will be# allowed to bind to ports 21 or 2001.
.
SocketBindTight on# proftpd creates two sockets again, however one is bound to 10.0.0.1, port 21# and the other to 10.0.0.2, port 2001. Because these sockets are "tightly"# bound to IP addresses, port 21 can be reused on any address OTHER than# 10.0.0.1, and visa-versa with 10.0.0.2, port 2001.
One side-effect of setting SocketBindTight to on is that connections to non-bound addresses will
result in a "connection refused" message rather than the typical "500 Sorry, no server available to
handle request on xxx.xxx.xxx.xxx.", due to the fact that no listen socket has been bound to the
particular address/port pair. This may or may not be aesthetically desireable, depending on your
circumstances.
SyslogFacility
Syntax: SyslogFacility facility-level
Default: none
Context: server config
Compatibility: 1.1.6 and later
Proftpd logs it’s activity via the Unix syslog mechanism, which allows for several different generalclassifications of logging messages, known as "facilities." Normally, all authentication relatedmessages are logged with the AUTHPRIV (or AUTH) facility [intended to be secure, and neverseen by unwanted eyes], while normal operational messages are logged with the DAEMON facility.
The SyslogFacility directive allows ALL logging messages to be directed to a different facility thanthe default. When this directive is used, ALL logging is done with the specificed facility, bothauthentication (secure) and otherwise.
The facility-level argument must be one of the following: AUTH (or AUTHPRIV), CRON,
DAEMON, KERN, LPR, MAIL, NEWS, USER, UUCP, LOCAL0, LOCAL1, LOCAL2,
LOCAL3, LOCAL4, LOCAL5, LOCAL6 or LOCAL7.
tcpBackLog
Syntax: tcpBackLog backlog-size
Default: tcpBackLog 5
Context: server config
Compatibility: 0.99.0 and later
The tcpBackLog directive controls the tcp "backlog queue" when listening for connections in
standalone mode (see ServerType). It has no affect upon servers in inetd mode. When a tcp
connection is established by the tcp/ip stack inside the kernel, there is a short period of time
between the actual establishment of the connection and the acceptance of the connection by a
user-space program. The duration of this latency period is widely variable, and can depend upon
several factors (hardware, system load, etc). During this period tcp connections cannot be accepted,
as the port that was previouisly "listening" has become filled with the new connection. Under heavy
connection load this can result in occasional (or even frequent!) "connection refused" messages
returned to the incoming client, even when there is a service available to handle requests. To
eliminate this problem, most modern tcp/ip stacks implement a "backlog queue" which is simply a
pre-allocation of resources necessary to handle backlog-size connections during the latency period.
The larger the backlog queue, the more connections can be established in a very short time period.
The trade-off, of course, is kernel memory and/or other kernel resources.
Generally it is not necessary to use a tcpBackLog directive, unless you intend to service a largenumber of virtual hosts (see <VirtualHost>), or have a consistantly heavy system load. If you beginto notice or hear of "connection refused" messages from remote clients, try setting a slightly highervalue to this directive.
tcpReceiveWindow
Syntax: tcpReceiveWindow window-size
Default: tcpReceiveWindow 8192
Context: server config, <VirtualHost>
Compatibility: 0.99.0 and later
The tcpReceiveWindow directive configures the size (in octets) of all data connections’ tcp receivewindows. It is only used when receiving a file from a client over the data connection. Typically, agiven tcp/ip implementation will use a relatively small receive window size (the number of octetsthat can be received at the tcp layer before a "turnaround" acknowledgement is required). Whentransfering a large amount of data over fast digital transmission lines which have a relatively highlatency, a small receive window can dramatically affect perceived throughput because of thenecessity to completely stop the transfer occasionally in order to wait for the remote endpoint toreceive the acknowledgement and continue transmission. For example, on a T1 line (assuming full1.544Mbps endpoint-to-endpoint throughput) with 100 ms latency, a 4k receive buffer will verydramatically reduce the perceived throughput. The default value of 8192 octets (8k) should bereasonable in common network configurations.
Additionally, proftpd allocates its internal buffers to match the receive/send window sizes; in orderto maximize the reception/transmission performance (reducing the number of times data must betransfered from proftpd to the kernel tcp/ip stack). The tradeoff, of course, is memory; both kernel-and user-space. If running proftpd on a memory tight host (and on a low-bandwidth connection), itmight be advisable to decrease both the tcpReceiveWindow and tcpSendWindow sizes.
tcpSendWindow
Syntax: tcpSendWindow window-size
Default: tcpSendWindow 8192
Context: server config, <VirtualHost>
Compatibility: 0.99.0 and later
The tcpSendWindow directive configures the size (in octets) of all data connections’ tcp sendwindows. It is only used when sending a file from the server to a client on the data connection. For a detailed description of receive/send window sizes see tcpReceiveWindow.
TimeoutIdle
Syntax: TimeoutIdle seconds
Default: TimeoutIdle 600
Context: server config
Compatibility: 0.99.0 and later
The TimeoutIdle directive configures the maximum number of seconds that proftpd will allowclients to stay connected without receiving any data on either the control or data connection. If datais received on either connection, the idle timer is reset. Setting TimeoutIdle to 0 disables the idletimer completely (clients can stay connected for ever, without sending data). This is generally a badidea as a "hung" tcp connection which is never properly disconnected (the remote network mayhave become disconnected from the Internet, etc) will cause a child server to never exit (at least notfor a considerable period of time) until manually killed See also: TimeoutLogin, TimeoutNoTransfer TimeoutLogin
Syntax: TimeoutLogin seconds
Default: TimeoutLogin 300
Context: server config
Compatibility: 0.99.0 and later
The TimeoutLogin directive configures the maximum number of seconds a client is allowed tospend authenticating. The login timer is not reset when a client transmits data, and is only removedonce a client has transmitted an acceptable USER/PASS command combination.
TimeoutNoTransfer
Syntax: TimeoutNoTransfer seconds
Default: TimeoutNoTransfer 600
Context: server config
Compatibility: 0.99.0 and later
The TimeoutNoTransfer directive configures the maximum number of seconds a client is allowedto spend connected, after authentication, without issuing a command which results in creating anactive or passive data connection (i.e. sending/receiving a file, or receiving a directory listing).
Syntax: Umask octal-mask
Default: UseFtpUsers on
Context: server config, <Anonymous>, <VirtualHost>, <Directory>, .ftpaccess
Compatibility: 0.99.0 and later
Umask sets the mask applied to newly created file and directory permissions within a given context.
By default, the Umask in the server configuration, <VirtualHost> or <Anonymous> block is used,unless overridden by a "per-directory" Umask setting. The argument supplied must be an octalnumber, in the format 0xxx. For more information on umasks, consult your operating systemdocumentation/man pages.
UseFtpUsers
Syntax: UseFtpUsers on|off
Default: UseFtpUsers on
Context: server config, <Anonymous>, <VirtualHost>
Compatibility: 0.99.0 and later
Legacy FTP servers generally check a special authorization file (typically /etc/ftpusers) when aclient attempts to authenticate. If the user’s name is found in this file, FTP access is denied. Forcompatibility sake, proftpd defaults to checking this file during authentication. This behavior can besupressed using the UseFtpUsers configuration directive.
Syntax: User userid
Default: None
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0 and later
The User directive configures which user the proftpd daemon will normally run as. By default,
proftpd runs as root which is considered undesireable in all but the most trustful network
configurations. The User directive used in conjuction with the Group directive instructs the daemon
to switch to the specified user and group as quickly as possible after startup. On some unix variants,
the daemon will occasionally switch back to root in order to accomplish a task which requires
super-user access. Once the task is completed, root privileges are relinquished and the server
continues to run as the specified user and group. When applied to a <VirtualServer> block, proftpd
will run as the specified user/group on connections destined for the virtual server’s address or port.
If either User or Group is applied to an <Anonymous> block, proftpd will establish an anonymous
login when a user attempts to login with the specified userid, as well as permanently switching tothe corresponding uid/gid (matching the User/Group parameters found in the anonymous block)after login.
Note: When an authorized unix user is authenticated and logs in, all former privileges are released,the daemon switches permanently to the logged in user’s uid/gid, and is never again capable ofswitching back to root or any other user/group.
UserAlias
Syntax: UserAlias login-user userid
Default: None
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0 and later
The UserAlias directive creates a mapping from a login name transmitted by a client (login-user) to
a real system userid (userid). If the user logs in as the alias, authentication is performed as though
they were actually logging in as the real user. This directive is often used inside an <Anonymous>
block in order to allow multiple login names to activate an anonymous login. Note: If the
login-user parameter is the same as a real system userid, the real userid will no longer be
recognized by proftpd.
UserPassword
Syntax: UserPassword userid hashed-password
Default: None
Context: server config,<VirtualHost>, <Anonymous>
Compatibility: 0.99.0pl5 and later
The UserPassword directive creates a password for a particular user which overrides the user’s
normal password in /etc/passwd (or /etc/shadow). The override is only effective inside the context
to which UserPassword is applied. The hashed-password argument is a cleartext string which has
been passed through the standard unix crypt() function. Do NOT use a cleartext password. This
can be useful when combined with UserAlias to provide multiple logins to an Anonymous FTP site.
<VirtualHost>
Syntax: <VirtualHost address>
Default: None
Context: server config
Compatibility: 0.99.0 and later
The VirtualHost configuration block is used to create an independent set of configuration directives
that apply to a particular hostname or IP address. It is often used in conjuction with system level IP
aliasing or dummy network interfaces in order to establish one or more "virtual" servers which all
run on the same physical machine. The block is terminated with a </VirtualHost> directive. By
utilizing the Port directive inside a VirtualHost block, it is possible to create a virtual server which
uses the same address as the master server, but listens on a seperate tcp port (incompatible with
ServerType inetd).
When proftpd starts, virtual server connections are handled in one of two ways, depending on theServerType setting: inetd
The daemon examines the destination address and port of the incoming connection handed off
from inetd. If the connection matches one of the configured virtual hosts, the connection is
serviced based on the appropriate configuration. If no virtual host matches, and the main
server does not match, the client is informed that no server is available to service their
requests and disconnected.
standalone
After parsing the configuration file, the daemon begins listening for connections on all
configured ports, spawning child processes as necessary to handle connections for either the
main server or any virtual servers.
Because of the method that the daemon uses to listen for connections when in standalone mode, it
is possible to support an exceedingly large number of virtual servers, potentially exceeding the
number of per-process file descriptors. This is due to the fact that a single file descriptor is used to
listen to each configured port, regardless of the number of addresses being monitored. Note that it
may be necessary to increase the tcpBackLog value on heavily loaded servers in order to avoid
kernel rejected client connections ("Connection refused").

Source: ftp://ftp.ihg.uni-duisburg.de/docs/ProFTPD-reference.pdf