| Server IP : 62.109.13.187 / Your IP : 216.73.216.11 [ Web Server : Apache/2.4.6 (CentOS) mpm-itk/2.4.7-04 OpenSSL/1.0.2k-fips PHP/8.2.28 System : Linux robothost.ru 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 User : mosrembit ( 6064) PHP Version : 8.2.28 Disable Function : NONE Domains : 0 Domains MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /usr/share/doc/proftpd-1.3.5e/modules/ |
Upload File : |
<!-- $Id: mod_auth_file.html,v 1.6 2014-01-22 04:18:09 castaglia Exp $ --> <!-- $Source: /home/proftpd-core/backup/proftp-cvsroot/proftpd/doc/modules/mod_auth_file.html,v $ --> <html> <head> <title>ProFTPD module mod_auth_file</title> </head> <body bgcolor=white> <hr> <center> <h2><b>ProFTPD module <code>mod_auth_file</code></b></h2> </center> <hr><br> This module is contained in the <code>mod_auth_file.c</code> file for ProFTPD 1.3.<i>x</i>, and is compiled by default. <h2>Directives</h2> <ul> <li><a href="#AuthGroupFile">AuthGroupFile</a> <li><a href="#AuthUserFile">AuthUserFile</a> </ul> <hr> <h2><a name="AuthGroupFile">AuthGroupFile</a></h2> <strong>Syntax:</strong> AuthGroupFile <em>path [id min-max] [name regex]</em><br> <strong>Default:</strong> None<br> <strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br> <strong>Module:</strong> mod_auth_file<br> <strong>Compatibility:</strong> 1.2.7rc2 <p> The <code>AuthGroupFile</code> directive configures an alternate group file for providing group membership information; the specified file must have the same format as the system <code>/etc/group</code> file, and if specified is used during authentication and group lookups for directory/access control operations. The <em>path</em> argument should be the full path to the specified file. This directive can be configured on a per-server basis, so that virtual FTP servers can each have their own authentication file, often in conjunction with an <a href="#AuthUserFile"><code>AuthUserFile</code></a>. <p> Note that this file does <i>not</i> need to reside inside a <code>chroot()</code>ed directory structure for anonymous or <code>DefaultRoot</code> logins, as it is held open for the duration of a session. <p> The optional parameters are used to set restrictions on the contents of the specified file. The <em>id</em> restriction is used to specify a range of GIDs that may appear in the file; when doing a lookup, if a group entry has a GID that is less than the minimum or greater than the maximum is encountered, that entry is ignored. The <em>name</em> restriction is used to specify a regular expression that is applied to the name of a group entry. If the group name does not match the regular expression, the group entry is ignored. A leading <code>!</code> in the regular expression can be used to negate the given expression. <p> Example: <pre> # This makes an AuthGroupFile that can only have GIDs 2000 to 4000, and # whose groups must start with 'cust' AuthGroupFile /etc/ftpd/group id 2000-4000 name ^cust </pre> <p> <b>Note</b>: In order to prevent other users from modifying the <code>AuthGroupFile</code>, the <code>mod_auth_file</code> module <b>requires</b> that the permissions on the file <b>not</b> be world-readable <b>or</b> world-writable, <b>and</b> that the directory containing the file <b>not</b> be world-writable. In addition, if the file is not a file (<i>e.g.</i> the path points to a symlink, or a FIFO, <i>etc</i>), a warning will be logged on server startup/restart. <p> <hr> <h2><a name="AuthUserFile">AuthUserFile</a></h2> <strong>Syntax:</strong> AuthUserFile <em>path [id min-max] [home regex] [name regex]</em><br> <strong>Default:</strong> None<br> <strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br> <strong>Module:</strong> mod_auth_file<br> <strong>Compatibility:</strong> 1.2.7rc2 <p> The <code>AuthUserFile</code> directive configures an alternate passwd file for providing user account information; the specified file must have the same format as the system <code>/etc/passwd</code> file, and if specified is used during authentication and user lookups for directory/access control operations. The <em>path</em> argument should be the full path to the specified file. This directive can be configured on a per-server basis, so that virtual FTP servers can each have their own authentication file, often in conjunction with an <a href="#AuthGroupFile"><code>AuthGroupFile</code></a>. <p> Note that this file does <i>not</i> need to reside inside a <code>chroot()</code>ed directory structure for anonymous or <code>DefaultRoot</code> logins, as it is held open for the duration of a session. <p> The optional parameters are used to set restrictions on the contents of the specified file. The <em>id</em> restriction is used to specify a range of UIDs that may appear in the file; when doing a lookup, if a user entry has a UID that is less than the minimum or greater than the maximum is encountered, that entry is ignored. The <em>home</em> restriction is used to specify a regular expression that is applied to the home directory of a user entry. If the home does not match the regular expression, the user entry is ignored. The <em>name</em> restriction is used to specify a regular expression that is applied to the name of a user entry. If the user name does not match the regular expression, the user entry is ignored. A leading <code>!</code> in these regular expressions can be used to negate the given expression. <p> Example: <pre> # This makes an AuthUserFile whose user names must start with 'ftp', and # whose homes cannot start with /home. AuthUserFile /etc/ftpd/passwd name ^ftp home !^/home </pre> <p> <b>Note</b>: In order to prevent other users from modifying the <code>AuthUserFile</code>, the <code>mod_auth_file</code> module <b>requires</b> that the permissions on the file <b>not</b> be world-readable <b>or</b> world-writable, <b>and</b> that the directory containing the file <b>not</b> be world-writable. In addition, if the file is not a file (<i>e.g.</i> the path points to a symlink, or a FIFO, <i>etc</i>), a warning will be logged on server startup/restart. <p> <hr> <h2><a name="Installation">Installation</a></h2> The <code>mod_auth_file</code> module is compiled by default. <p><a name="FAQ"> <b>Frequently Asked Questions</b><br> <p><a name="Password8Characters"> <font color=red>Question</font>: I found that only the first 8 characters of passwords are used! This is a security bug!<br> <font color=blue>Answer</font>: No, it is not. <p> The default Unix password hashing scheme uses the <a href="http://en.wikipedia.org/wiki/Data_Encryption_Standard">Data Encryption Standard</a> (DES) algorithm. As per the <code>crypt(3)</code> man page, <b>only the first 8 characters of the password are used</b>. Thus this 8 character limitation comes from the underlying system authentication, <b>not</b> from proftpd. The whole purpose of the PAM system was to enable replacing the use of DES with other authentication algorithms, which do not have this 8 character limitation. <p> Later, other <code>crypt(3)</code> implementations were made which can also support algorithms such as MD5, or Blowfish. Some platforms support these enhanced versions of <code>crypt(3)</code>, some do not. The <a href="../utils/ftpasswd.html"><code>ftpasswd</code></a> script can generate <code>AuthUserFiles</code> which use the MD5 algorithm instead of DES. <p><a name="AuthFilePermissions"> <font color=red>Question</font>: Why does <code>mod_auth_file</code> refuse to use an <code>AuthUserFile</code> (or <code>AuthGroupFile</code>) that is world-readable/writable? I see messages like the following logged: <pre> mod_auth_file/1.0: unable to use world-readable AuthUserFile '/etc/proftpd/ftpd.passwd' </pre> or: <pre> mod_auth_file/1.0: unable to use world-writable AuthUserFile '/etc/proftpd/ftpd.passwd' </pre> <br> <font color=blue>Answer</font>: If an <code>AuthUserFile</code> or <code>AuthGroupFile</code> is world-writable, then <b>any user on the system can edit that file</b>. They can create new users, or change the entries for existing users such that those users have different privileges, perhaps even root privileges. In short, having <code>AuthUserFile<code> or <code>AuthGroupFile</code> with world-writable permissions is an unsafe configuration, and now <code>mod_auth_file</code> prevents this. <p> If the <code>AuthUserFile</code> is world-readable, then <b>any user on the system can read that file</b>, including the hashed password. This can allow for offline dictionary/cracking attempts against those hashes. This is also an unsafe configuration, and thus <code>mod_auth_file</code> does not allow world-readable <code>AuthUserFiles</code>. <p> Similarly, <code>mod_auth_file</code> will refuse to use an <code>AuthUserFile</code> or <code>AuthGroupFile</code> if that file lives in a directory, and that directory has world-writable permissions (even if the configured file itself is <b>not</b> world-writable). A world-writable directory would allow <b>any system user to delete the <code>AuthUserFile</code></b>, and add their own, or to add a symlink, <i>etc</i>. It is another unsafe configuration against which <code>mod_auth_file</code> now guards. <p> <hr><br> Author: <i>$Author: castaglia $</i><br> Last Updated: <i>$Date: 2014-01-22 04:18:09 $</i><br> <br><hr> <font size=2><b><i> © Copyright 2002-2014<br> All Rights Reserved<br> </i></b></font> <hr><br> </body> </html>