Ergebnis 1 bis 9 von 9

  1. Beiträge
    109
    Registriert seit
    06.04.2001
    Erfahrener Benutzer

    ProFTPD und .htaccess verstecken

    Hallo!

    Ich würde gerne alle Dateien die mit .htaccess und mit .qmail anfangen verstecken. Alle anderen, die mit . beginnen sollen gezeigt werden!

    Gibt es eine Möglichkeit?

    Disaster

  2. Registrieren, damit diese Werbung verschwindet.

  3. Beiträge
    1.176
    Registriert seit
    22.03.2001
    Foren-Guru

    RE: ProFTPD und .htaccess verstecken

    probier mal

    PathDenyFilter "(\.htaccess)|(\.qmail)"

    - ohne gewaehr - ;-)


  4. Beiträge
    109
    Registriert seit
    06.04.2001
    Erfahrener Benutzer

    RE: ProFTPD und .htaccess verstecken

    Danke!

    Das war das, was ich gesucht habe in der Docu.

    Disaster


  5. Beiträge
    109
    Registriert seit
    06.04.2001
    Erfahrener Benutzer

    RE: ProFTPD und .htaccess verstecken

    tja, zu früh gefreut. Der User darf nun solche Dateinamen nicht uploaden, aber ich will ja, dass er Sie nicht mal sieht...

    Disaster


  6. Beiträge
    1.176
    Registriert seit
    22.03.2001
    Foren-Guru

    RE: ProFTPD und .htaccess verstecken

    habs ja auch nicht auswendig im kopf, aber so wie ich mal kurz in die doku reingespickt habe, muss man wohl mit

    <limit>
    ignorehidden
    und
    hidenoaccess

    arbeiten.

    oder probier einfach mal

    DenyFilter \*.*/



  7. Beiträge
    109
    Registriert seit
    06.04.2001
    Erfahrener Benutzer

    RE: ProFTPD und .htaccess verstecken

    Danke!

    Leider auch alles nicht richtig... bzw. hatte ich mir schon angeguckt.

    irgnoehidden und hidenoaccess sind soweit ich es verstanden habe nur für Directory's und die kann man damit halt ein / ausschalten.

    DenyFilter hingegen bezieht sich nur auf Kommando's, die ausgeführt werden dürfen...

    anscheinend gibt es keine Möglichkeit in ProFTPD... schade

    Disaster


  8. Beiträge
    1.176
    Registriert seit
    22.03.2001
    Foren-Guru

    RE: ProFTPD und .htaccess verstecken

    doch, gibt es - soweit ich weiss - schon.

    wenn ich nachher mal zeit und lust hab schau ich evtl. mal genauer nach.


  9. Beiträge
    2.467
    Registriert seit
    24.02.2001
    Ort
    Saarbrücken/Frankfurt
    Alter
    50
    Foren-Guru

    RE: ProFTPD und .htaccess verstecken

    Directive List
    Notes
    This document is valid for 1.2.5rc1
    SQL support was merged from three into a single module (mod_sql) after 1.2.0rc3
    Alphabetical List of Directives
    The following configuration parameters control ProFTPD features and configuration:


    --------------------------------------------------------------------------------

    AccessDenyMsg
    AccessGrantMsg
    Allow
    AllowAll
    AllowChmod (Deprecated)
    AllowFilter
    AllowForeignAddress
    AllowGroup
    AllowLogSymlinks
    AllowOverwrite
    AllowRetrieveRestart
    AllowStoreRestart
    AllowUser
    AnonRatio Incomplete
    AnonRequirePassword
    <Anonymous>
    AnonymousGroup
    AuthAliasOnly
    AuthGroupFile
    AuthPAM
    AuthPAMAuthoritative
    AuthPAMConfig
    AuthUserFile
    AuthUsingAlias
    Bind
    ByteRatioErrMsgIncomplete
    CDPath
    Class
    Classes
    CommandBufferSize
    CwdRatioMsgIncomplete
    DefaultChdir
    DefaultQuota
    DefaultRoot
    DefaultServer
    DefaultTransferMode
    DeferWelcome
    DeleteAbortedStores
    Deny
    DenyAll
    DenyFilter
    DenyGroup
    DenyUser
    <Directory>
    DirFakeGroup
    DirFakeMode
    DirFakeUser
    DisplayConnect
    DisplayFirstChdir
    DisplayGoAway
    DisplayLogin
    DisplayQuit
    DisplayReadme
    ExtendedLog
    FileRatioErrMsg Incomplete
    FooBarDirective
    <Global>
    Group
    GroupOwner
    GroupPassword
    GroupRatio Incomplete
    HiddenStor
    HideGroup
    HideNoAccess
    HideUser
    HostRatio Incomplete
    HostsAllowSyslogLevel
    HostsDenySyslogLevel
    IdentLookups
    IgnoreHidden
    Include
    <Limit>
    LDAPAuthBinds
    LDAPDefaultAuthScheme
    LDAPDefaultGID
    LDAPDefaultUID
    LDAPDNInfo
    LDAPDoAuth
    LDAPDoUIDLookups
    LDAPDoGIDLookups
    LDAPForceDefaultGID
    LDAPForceDefaultUID
    LDAPHomedirOnDemand
    LDAPHomedirOnDemandPrefix
    LDAPHomedirOnDemandPrefixNoUsername
    LDAPHomedirOnDemandSuffix
    LDAPNegativeCache
    LDAPQueryTimeout
    LDAPSearchScope
    LDAPServer
    LDAPUseTLS
    LeechRatioMsg
    LogFormat
    LoginPasswordPrompt
    LsDefaultOptions
    MasqueradeAddress
    MaxClients
    MaxClientsPerHost
    MaxHostsPerUser
    MaxInstances
    MaxLoginAttempts
    MultilineRFC2228
    MySQLInfo
    Order
    PassivePorts
    PathAllowFilter
    PathDenyFilter
    PersistentPasswd
    PidFile
    Port
    PostgresInfo
    PostgresPort
    Quotas
    QuotaBlockSize
    QuotaBlockName
    QuotaCalc
    QuotaExempt
    QuotaType
    RateReadBPS
    RateReadFreeBytes
    RateReadHardBPS
    RateWriteBPS
    RateWriteFreeBytes
    RateWriteHardBPS
    RatioFile Incomplete
    Ratios Incomplete
    RatioTempFile Incomplete
    RequireValidShell
    RLimitCPU
    RLimitMemory
    RLimitOpenFiles
    RootLogin
    SaveRatios Incomplete
    ScoreboardPath
    ServerAdmin
    ServerIdent
    ServerName
    ServerType
    ShowDotFiles
    ShowSymlinks
    SocketBindTight
    SQLAuthenticate
    SQLAuthTypes
    SQLAuthoritative
    SQLConnectInfo
    SQLDefaultGID
    SQLDefaultGID
    SQLDefaultHomedir
    SQLDefaultUID
    SQLDoAuth
    SQLDoGroupAuth
    SQLEmptyPasswords (Deprecated use SQLAuthTypes)
    SQLEncryptedPasswords (Deprecated use SQLAuthTypes)
    SQLGidField
    SQLGroupGidField
    SQLGroupInfo
    SQLGroupMembersField
    SQLGroupnameField
    SQLGroupTable
    SQLGroupWhereClause
    SQLHomedir
    SQLHomedirField
    SQLHomedirOnDemand
    SQLKey (Deprecated use SQLWhereClause)
    SQLKeyField (Deprecated use SQLWhereClause)
    SQLLog
    SQLLogDirs
    SQLLogHits
    SQLLogHosts
    SQLLoginCountField
    SQLLogStats
    SQLMinUserGID
    SQLMinID
    SQLMinUserUID
    SQLNamedQuery
    SQLPasswordField
    SQLPlaintextPasswords (Deprecated use SQLAuthTypes)
    SQLProcessGrEnt
    SQLProcessPwEnt
    SQLRatios Incomplete
    SQLRatioStats
    SQLShellField
    SQLShowInfo
    SQLUidField
    SQLUserInfo
    SQLUserTable
    SQLUsernameField
    SQLUserWhereClause
    SQLWhereClause
    SyslogFacility
    SyslogLevel
    SystemLog
    TCPAccessFiles
    TCPAccessSyslogLevels
    tcpBackLog
    TCPGroupAccessFiles
    tcpNoDelay
    tcpReceiveWindow
    tcpSendWindow
    TCPUserAccessFiles
    TimesGMT
    TimeoutIdle
    TimeoutLogin
    TimeoutNoTransfer
    TimeoutStalled
    TransferLog
    Umask
    UseFtpUsers
    UseGlobbing
    UseHostsAllowFile
    UseHostsDenyFile
    UseReverseDNS
    User
    UserDirRoot
    UserAlias
    UserOwner
    UserPassword
    UserRatio Incomplete
    <VirtualHost>
    WtmpLog

    --------------------------------------------------------------------------------

    AccessDenyMsg
    Syntax: AccessDenyMsg "message"
    Default: Dependent on login type
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.2.2 and later

    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." It is 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.

    Example:

    AccessDenyMsg "Access for %u has been denied"

    --------------------------------------------------------------------------------

    AccessGrantMsg
    Syntax: AccessGrantMsg "message"
    Default: Dependent on login type
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    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."

    --------------------------------------------------------------------------------

    Allow
    Syntax: Allow ["from"] "all"|"none"|host|network[,host|network[,...]]
    Default: allow all
    Context: <Limit>
    Module: mod_core
    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 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) or be specified in CIDR format.. Named address which specify an entire network should begin with a trailing period (i.e. .proftpd.org for the entire proftpd.org domain).

    The selection made can be selectively negated using the ! operator, this allows a large block of hosts or IPs to be selected while still allowing single hosts to be weeded out as required.

    Example:

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

    --------------------------------------------------------------------------------

    AllowAll
    Syntax: AllowAll
    Default: Default is to implicitly AllowAll, but not explicitly
    Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
    Module: mod_core
    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.


    --------------------------------------------------------------------------------

    AllowChmod
    Syntax: AllowChmod on|off
    Default: true
    Context: server config, <Directory>, <VirtualHost>, <Anonymous>, <Global>, .ftpaccess
    Module: mod_site
    Compatibility: 1.2.0rc1 and later

    This directive is deprecated, use <Limit SITE_CHMOD> instead.


    --------------------------------------------------------------------------------

    AllowFilter
    Syntax: AllowFilter regular-expression
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre7 and later

    AllowFilter allows the configuration of a regular expression that must be matched for all commands 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 entire 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. Command filtering is not applied to passwords (arguments to the PASS command).

    If the regular-expression argument contains whitespace, it must be enclosed in quotes.

    Example:

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


    --------------------------------------------------------------------------------

    AllowForeignAddress
    Syntax: AllowForeignAddress on|off
    Default: off
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.1.7 and later

    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.


    --------------------------------------------------------------------------------

    AllowGroup
    Syntax: AllowGroup group-expression
    Default: None
    Context: <Limit>
    Module: mod_core
    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 separated 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.

    See Also: DenyGroup, DenyUser, AllowUser


    --------------------------------------------------------------------------------

    AllowLogSymlinks
    Syntax: AllowLogSymlinks on|off
    Default: off
    Context: server config, <VirtualHost>, <Global>
    Module: mod_log
    Compatibility: 1.2.2rc2 and later

    By default, the server will the path of any configured SystemLog 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 via this directive.

    Security note: this behaviour should not be allowed unless for a very good reason. By allowing the server to open symbolic links with its root privileges, you are allowing a potential symlink attack where the server could be tricked into overwriting arbitrary system files. You have been warned.


    --------------------------------------------------------------------------------

    AllowOverwrite
    Syntax: AllowOverwrite on|off
    Default: off
    Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
    Module: mod_core
    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.


    --------------------------------------------------------------------------------

    AllowUser
    Syntax: AllowUser user-expression
    Default: None
    Context: <Limit>
    Module: mod_core
    Compatibility: 1.1.7 and later

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

    See Also: DenyUser, DenyGroup, AllowGroup


    --------------------------------------------------------------------------------

    AllowRetrieveRestart
    Syntax: AllowRetrieveRestart on|off
    Default: on
    Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.


    --------------------------------------------------------------------------------

    AllowStoreRestart
    Syntax: AllowStoreRestart on|off
    Default: off
    Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
    Module: mod_core
    Compatibility: 0.99.0 and later

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


    --------------------------------------------------------------------------------

    AnonRequirePassword
    Syntax: AnonRequirePassword on|off
    Default: off
    Context: <Anonymous>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.

    Example of a "guest" account configuration:

    <Anonymous ~roger>
    User roger
    Group other
    UserAlias proftpd roger
    AnonRequirePassword 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 are
    # command-group limits, we can explicitly permit certain operations which
    # will take precedence 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>

    --------------------------------------------------------------------------------

    AnonRatio
    Syntax: AnonRatio foo1 foo2 foo3
    Default: None known
    Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
    Module: mod_ratio
    Compatibility: at least 1.2.0 and later

    The AnonRatio directive .... INCOMPLETE

    Example:

    AnonRatio

    --------------------------------------------------------------------------------

    <Anonymous>
    Syntax: <Anonymous root-directory>
    Default: None
    Context: server config,<VirtualHost>, <Global>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.

    Example of a typical anonymous FTP configuration:

    <Anonymous /home/ftp>
    # After anonymous logins, daemon runs as user ftp
    User ftp

    # After anonymous logins, daemon runs as group ftp
    Group ftp

    # Clients that login as 'anonymous' are aliased to 'ftp'
    UserAlias anonymous 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>, <Global>
    Module: mod_core
    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 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.


    --------------------------------------------------------------------------------

    AuthAliasOnly
    Syntax: AuthAliasOnly on|off
    Default: off
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.1.3 and later

    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.


    --------------------------------------------------------------------------------

    AuthGroupFile
    Syntax: AuthGroupFile path
    Default: None
    Context: server config, <VirtualHost>, <Global>
    Module: mod_unixpw
    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 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.


    --------------------------------------------------------------------------------

    AuthPAM
    Syntax: AuthPAM on|off
    Default: on
    Context: server config,<VirtualHost>, <Global>
    Module: mod_pam
    Compatibility: 1.2.0rc1 and later

    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.


    --------------------------------------------------------------------------------

    AuthPAMAuthoritative
    Syntax: AuthPAMAuthoritative on|off
    Default: off
    Context: server config,<VirtualHost>, <Global>
    Module: mod_unixpw
    Compatibility: 1.2.0pre3 and later

    This directive allows you to control whether or not PAM is the ultimate authority on authentication. Setting this directive to on will cause authentication to fail if PAM authentication fails. The default setting, off, allows other modules and directives such as AuthUserFile and friends to authenticate users, should PAM authentication fail.

    If you are having problems with PAM and using other directives like AuthUserFile, set this directive to off.


    --------------------------------------------------------------------------------

    AuthPAMConfig
    Syntax: AuthPAMConfig service
    Default: ftp
    Context: server config,<VirtualHost>, <Global>
    Module: mod_pam
    Compatibility: 1.2.0rc1 and later

    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

    Example:

    # Virtual host foobar authenticates differently than the rest
    AuthPAMConfig foobar
    This assumes you have a PAM service named foobar configured in your /etc/pam.conf file or /etc/pam.d directory.


    --------------------------------------------------------------------------------

    AuthUserFile
    Syntax: AuthUserFile path
    Default: None
    Context: server config,<VirtualHost>, <Global>
    Module: mod_unixpw
    Compatibility: 1.0.3/1.1.1 and later

    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.


    --------------------------------------------------------------------------------

    AuthUsingAlias
    Syntax: AuthUsingAlias on|off
    Default: off
    Context: <Anonymous>
    Module: mod_core
    Compatibility: 1.2.0pre9 and later

    Normally, when the AnonRequirePassword directive is used, the authentication is done using the password entry of the daemon process. However under certain circumstances it may be required for the authentication to be done using the login username & password instead.

    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>

    --------------------------------------------------------------------------------

    Bind
    Syntax: Bind address
    Default: None
    Context: server config, <VirtualHost>
    Module: mod_core
    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.


    --------------------------------------------------------------------------------

    ByteRatioErrMsg
    Syntax: ByteRatioErrMsg foo1 foo2 foo3
    Default: None known
    Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
    Module: mod_ratio
    Compatibility: at least 1.2.0 and later

    The ByteRatioErrMsg directive .... INCOMPLETE

    Example:

    ByteRatioErrMsg

    --------------------------------------------------------------------------------

    CDPath
    Syntax: CDPath directory
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre2 and later

    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.


    --------------------------------------------------------------------------------

    Class
    Syntax: Class "name" limit|regex|ip value
    Default: None
    Context: server config, <VirtualHost>
    Module: mod_core
    Compatibility: 1.2.0pre9 and later

    Controls class based access. Class base access allows each connecting IP to be classified into a separate class. Each class has its own maximum number of connections. limit sets the maximum number of connections for that class name, regex sets a hostname regex (POSIX) for inclusion in the class and ip sets an IP/netmask based inclusion. The default class is called default.

    Example:

    Classes on
    Class local limit 100
    Class default limit 10
    Class local regex .*foo.com
    Class local ip 172.16.1.0/24
    This creates two classes, local and default, with local being everything in *.foo.com and 172.16.1.* combined.
    --------------------------------------------------------------------------------

    Classes
    Syntax: Classes on|off
    Default: Off
    Context: server config, <VirtualHost>
    Module: mod_core
    Compatibility: 1.2.0pre9 and later

    Controls class based access. Enables class based access control. see: Class


    --------------------------------------------------------------------------------

    CommandBufferSize
    Syntax: CommandBufferSize size
    Default: None
    Context: server config, <VirtualHost>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre7 and later

    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.


    --------------------------------------------------------------------------------

    CwdRatioMsg
    Syntax: CwdRatioMsg foo1 foo2 foo3
    Default: None known
    Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
    Module: mod_ratio
    Compatibility: at least 1.2.0 and later

    The CwdRatioMsg directive .... INCOMPLETE

    Example:

    CwdRatioMsg

    --------------------------------------------------------------------------------

    DefaultChdir
    Syntax: DefaultChdir directory [group-expression]
    Default: ~
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_auth
    Compatibility: 1.2.0pre2 and later

    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 the user will not be able to log in.


    --------------------------------------------------------------------------------

    DefaultQuota
    Syntax: DefaultQuota value in bytes
    Default: 0
    Context: server, <VirtualHost>, <Anonymous>
    Module: mod_quota
    Compatibility: at least 1.2.0 and later

    The DefaultQuota directive sets the default quota in bytes, this value is used if the .quota file does not exist.

    Example:

    # Set default to 1kb
    DefaultQuota 1024

    --------------------------------------------------------------------------------

    DefaultRoot
    Syntax: DefaultRoot directory [group-expression]
    Default: /
    Context: server config, <VirtualHost>, <Global>
    Module: mod_auth
    Compatibility: 0.99.0pl7 and later

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

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

    --------------------------------------------------------------------------------

    DefaultServer
    Syntax: DefaultServer on|off
    Default: off
    Context: server config,<VirtualHost>
    Module: mod_core
    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.


    --------------------------------------------------------------------------------

    DefaultTransferMode
    Syntax: DefaultTransferMode ascii|binary
    Default: ascii
    Context: server config, <VirtualHost>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre9 and later

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


    --------------------------------------------------------------------------------

    DeferWelcome
    Syntax: DeferWelcome on|off
    Default: off
    Context: server config, <VirtualHost>, <Global>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.


    --------------------------------------------------------------------------------

    DeleteAbortedStores
    Syntax: DeleteAbortedStores on|off
    Default: off
    Context: server, <VirtualHost>, <Directory>, <Anonymous>, <Global>, .ftpaccess
    Module: mod_core
    Compatibility: 1.2.0rc3 and later

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


    --------------------------------------------------------------------------------

    Deny
    Syntax: Deny ["from"] "all"|"none"|host|network[,host|network[,...]]
    Default: None
    Context: <Limit>
    Module: mod_core
    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.

    The selection made can be selectively negated using the ! operator, this allows a large block of hosts or IPs to be blocked while still allowing single hosts to be excluded from the filter.

    Example:

    Deny from example.net !trustedhost.example.net

    --------------------------------------------------------------------------------

    DenyAll
    Syntax: DenyAll
    Default: None
    Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
    Module: mod_core
    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 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.


    --------------------------------------------------------------------------------

    DenyFilter
    Syntax: DenyFilter regular-expression
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre7 and later

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

    Example:

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


    --------------------------------------------------------------------------------

    DenyGroup
    Syntax: DenyGroup group-expression
    Default: None
    Context: <Limit>
    Module: mod_core
    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 separated 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.

    See Also: AllowGroup, AllowUser, DenyUser


    --------------------------------------------------------------------------------

    DenyUser
    Syntax: DenyUser user-expression
    Default: None
    Context: <Limit>
    Module: mod_core
    Compatibility: 1.1.7 and later

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

    See Also: AllowUser, DenyGroup, AllowGroup


    --------------------------------------------------------------------------------

    <Directory>
    Syntax: <Directory pathname>
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.

    Example:

    <Directory /users/robroy/private>
    HideNoAccess
    </Directory>
    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 to the root of the server

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

    Example:

    <Directory ~/anon-ftp>
    <Limit WRITE>
    DenyAll
    </Limit>
    </Directory>

    --------------------------------------------------------------------------------

    DirFakeGroup
    Syntax: DirFakeGroup on|off [groupname]
    Default: DirFakeGroup off
    Context: server config, <VirtualHost>, <Anonymous>, <Global>, <Directory>, .ftpaccess
    Module: mod_ls
    Compatibility: 1.1.5

    DirFakeGroup and its 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>, <Directory>, <Global>
    Module: mod_ls
    Compatibility: 1.1.6

    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. For example:

    DirFakeMode 0640
    Will result in:

    -rw-r----- ... arbitrary.file
    drwxr-x--- ... arbitrary.directory
    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.


    --------------------------------------------------------------------------------

    DirFakeUser
    Syntax: DirFakeUser on|off [username]
    Default: off
    Context: server config, <VirtualHost>, <Anonymous>, <Global>, <Directory>, .ftpaccess
    Module: mod_ls
    Compatibility: 1.1.5

    See DirFakeGroup


    --------------------------------------------------------------------------------

    DisplayConnect
    Syntax: DisplayConnect filename
    Default: None
    Context: server config, <VirtualHost>, <Global>
    Module: mod_code
    Compatibility: 1.2.0pre2 and later

    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.


    --------------------------------------------------------------------------------

    DisplayFirstChdir
    Syntax: DisplayFirstChdir filename
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>
    Module: mod_code
    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 the user the first time they change into a directory (via CWD) per a given session. The file will also be displayed if proftpd detects that its last modification time has changed since the previous CWD into a given directory. If the filename is relative, it is looked for in the new directory that the user has changed into. Note that for anonymous ftp logins (see <Anonymous>), 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.

    DisplayFirstChdir, DisplayConnect, DisplayLogin, 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.

    %T Current Time
    %F Available space on file system
    %C Current working directory
    %R Remote host name
    %L Local host name
    %u Username reported by ident protocol
    %U Username originally used in login
    %M Max number of connections
    %N Current number of connections
    %E Server admin's e-mail address
    %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

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


    --------------------------------------------------------------------------------

    DisplayGoAway
    Syntax: DisplayGoAway filename
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre8 and later

    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


    --------------------------------------------------------------------------------

    DisplayLogin
    Syntax: DisplayLogin filename
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.


    --------------------------------------------------------------------------------

    DisplayQuit
    Syntax: DisplayQuit filename
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre8 and later

    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.


    --------------------------------------------------------------------------------

    DisplayReadme
    Syntax: DisplayReadme filename or pattern
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_readme
    Compatibility: 1.2.0pre8 and later


    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.

    Using:

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

    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.


    --------------------------------------------------------------------------------

    ExtendedLog
    Syntax: filename [[command-classes] format-nickname]
    Default: None
    Context: server config, <VirtualHost>, <Anonymous> <Global>
    Module: mod_log
    Compatibility: 1.1.6pl1 and later

    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. 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 (USER, PASS)
    INFO
    Informational commands (PWD, SYST, etc)
    DIRS
    Directory commands (LIST, CWD, MKD, etc)
    READ
    File reading (RETR)
    WRITE
    File/directory writing or creation
    MISC
    Miscellaneous commands (SITE, etc)
    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.

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

    ExtendedLog /var/log/ftp.log read,write
    See Also: LogFormat, TransferLog


    --------------------------------------------------------------------------------

    FileRatioErrMsg
    Syntax: FileRatioErrMsg foo1 foo2 foo3
    Default: None known
    Context: <Directory>, <Anonymous>, <Limit>,.ftpaccess
    Module: mod_ratio
    Compatibility: at least 1.2.0 and later

    The FileRatioErrMsg directive .... INCOMPLETE

    Example:

    FileRatioErrMsg

    --------------------------------------------------------------------------------

    FooBarDirective
    Syntax: FooBarDirective thingy
    Default: none
    Context: server config, <Anonymous>, <Limit>
    Module: mod_sample
    Compatibility: at least 1.2.0 and later

    FooBarDirective is a dummy directive to be used as a coding example only.


    --------------------------------------------------------------------------------

    <Global>
    Syntax: <Global>
    Default: None
    Context: server config, <VirtualHost>
    Module: mod_core
    Compatibility: 1.1.6 and later

    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.


    --------------------------------------------------------------------------------

    Group
    Syntax: Group groupid
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    Compatibility: 0.99.0 and later

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


    --------------------------------------------------------------------------------

    GroupOwner
    Syntax: GroupOwner groupname
    Default: None
    Context: <Anonymous>, <Directory>, .ftpaccess
    Module: mod_core
    Compatibility: 0.99.0 and later

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


    --------------------------------------------------------------------------------

    GroupPassword
    Syntax: GroupPassword groupid hashed-password
    Default: None
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_core
    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.

    See Also: UserPassword


    --------------------------------------------------------------------------------

    GroupRatio
    Syntax: GroupRatio foo1 foo2 foo3
    Default: None known
    Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
    Module: mod_ratio
    Compatibility: at least 1.2.0 and later

    The GroupRatio directive .... INCOMPLETE

    Example:

    GroupRatio

    --------------------------------------------------------------------------------

    HiddenStor
    Syntax: HiddenStor on|off
    Default: off
    Context: <Directory>, <Anonymous>, <VirtualHost>, <Global>
    Module: mod_core
    Compatibility: 1.2.0pre5 and later

    The HiddenStor 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 HiddenStor is enabled, with the server returning a 501 error code to the client.


    --------------------------------------------------------------------------------

    HideGroup
    Syntax: HideGroup groupid
    Default: None
    Context: <Directory>, <Anonymous>
    Module: mod_core
    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 on|off
    Default: None
    Context: <Directory>,<Anonymous>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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 to. 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: HideUser, HideGroup, IgnoreHidden


    --------------------------------------------------------------------------------

    HideUser
    Syntax: HideUser userid
    Default: None
    Context: <Directory>, <Anonymous>
    Module: mod_core
    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


    --------------------------------------------------------------------------------

    HostRatio
    Syntax: HostRatio foo1 foo2 foo3
    Default: None known
    Context: <Directory>, <Anonymous>, <Limit>, .ftpaccess
    Module: mod_ratio
    Compatibility: at least 1.2.0 and later

    The HostRatio directive .... INCOMPLETE

    Example:

    HostRatio

    --------------------------------------------------------------------------------

    HostsAllowSyslogLevel
    Syntax: HostsAllowSyslogLevel facility-level
    Default: none
    Context: server, <Anonymous>, <VirtualHost>
    Module: mod_wrap
    Compatibility: 1.2.0 and later

    Proftpd can log when a connection is allowed as the result of a rule in the file specified in UseHostsAllowFile to the Unix syslog mechanism. A discussion on the facility levels which can be used is given in the SyslogFacility directive

    .
    See Also: HostsDenySyslogLevel

    Example:

    HostsAllowSyslogLevel local3

    --------------------------------------------------------------------------------

    HostsDenySyslogLevel
    Syntax: HostsDenySyslogLevel facility-level
    Default: none
    Context: server, <Anonymous>, <VirtualHost>
    Module: mod_wrap
    Compatibility: 1.2.0 and later

    Proftpd can log when a connection is rejected as the result of a rule in the file specified in UseHostsAllowFile to the Unix syslog mechanism. A discussion on the facility levels which can be used is given in the SyslogFacility directive

    .
    See Also: HostsAllowSyslogLevel

    Example:

    HostsDenySyslogLevel local3

    --------------------------------------------------------------------------------

    IdentLookups
    Syntax: IdentLookups on|off
    Default: on
    Context: server config, <VirtualHost>, <Global>
    Module: mod_core
    Compatibility: 1.1.5 and later

    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.


    --------------------------------------------------------------------------------

    IgnoreHidden
    Syntax: IgnoreHidden on|off
    Default: off
    Context: <Limit>
    Module: mod_core
    Compatibility: 0.99.0 and later

    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.


    --------------------------------------------------------------------------------

    Include
    Syntax: Include file
    Default: None
    Context: server config, <Global>, <VirtualHost>, <Directory>, <Anonymous>
    Module: mod_core
    Compatibility: 1.2.0 and later

    This directive allows you to include another configuration file within your current configuration file.


    --------------------------------------------------------------------------------

    <Limit>
    Syntax: <Limit command|command-group [command2 ..]>
    Default: None
    Context: server config, <VirtualHost>, <Directory>, <Anonymous>, <Global>, .ftpaccess
    Module: mod_core
    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.
    SITE_CHMOD (CHange MODe bits)
    Change the permissions of files on 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). 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.
    ALL
    ALL FTP commands (identical to READ WRITE DIRS). Note this group has the lowest precedence of all, it will not override a limit generated by another command-group (ie 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.

    See Also: IgnoreHidden


    -------------


  10. Beiträge
    2.467
    Registriert seit
    24.02.2001
    Ort
    Saarbrücken/Frankfurt
    Alter
    50
    Foren-Guru

    RE: ProFTPD und .htaccess verstecken

    sorry für den letzten post! (kann gelöscht werden)

    hier der richtige:

    ShowDotFiles
    Syntax: ShowDotFiles on|off
    Default: Off
    Context: server config, <VirtualHost>, <Anonymous>, <Global>
    Module: mod_ls
    Compatibility: 0.99.0pl6 and later -- Deprecated

    If set to on, files starting with a '.', except for the directories '.' and '..', will be displayed in directory listings. This directive has been deprecated in favor of LsDefaultOptions -- e.g., LsDefaultOptions "-A" -- and may be removed in future versions.

    See Also: LsDefaultOptions

Ähnliche Themen

  1. proftpd mit mysql
    Von iON Media im Forum Webserver (Software): Linux, Unix, etc.
    Antworten: 13
    Letzter Beitrag: 02.08.2001, 18:06
  2. .htaccess Problem
    Von capt im Forum Webserver (Software): Linux, Unix, etc.
    Antworten: 1
    Letzter Beitrag: 30.07.2001, 12:50
  3. Problem eine .htaccess am laufen zu bekommen ;(
    Von Chipy im Forum Webserver (Software): Linux, Unix, etc.
    Antworten: 6
    Letzter Beitrag: 02.07.2001, 12:07
  4. Probleme mit .htaccess und Server
    Von Sven72 im Forum Webserver (Software): Linux, Unix, etc.
    Antworten: 7
    Letzter Beitrag: 26.06.2001, 08:20
  5. .htaccess Problem bei neuem Apache
    Von escape im Forum Webserver (Software): Linux, Unix, etc.
    Antworten: 1
    Letzter Beitrag: 27.05.2001, 16:21

Content Relevant URLs by vBSEO 3.6.0