ProFTPD module mod_auth

ProFTPD module `mod_auth_unix`

This module is contained in the mod_auth_unix.c file for ProFTPD 1.3.x, and is compiled by default.

Directives

AuthUnixOptions
PersistentPasswd

AuthUnixOptions

Syntax: AuthUnixOptions opt1 ...
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_auth_unix
Compatibility: 1.3.3rc2

The AuthUnixOptions directive is used to tweak various Unix-specific authentication behaviors in mod_auth_unix. The currently implemented options are:

AIXNoRLogin

In Bug#1896, support for checking some AIX-specific functions for whether a login should be accepted was added; this happens only on AIX servers, of course.
However, some AIX admins like to configure "rlogin=false", yet still want to allow FTP logins. To enable this specific behavior, a new AuthUnixOptions setting (only honored on AIX) was added:
```
        AuthUnixOptions AIXNoRLogin
```
If this setting is used on any other server, it is silently ignored. Bug#3300 has the full details.

MagicTokenChroot

This option causes mod_auth_unix to examine the home directory retrieved for a user for the magic "/./" token. If found, the portion of the directory before the token will be used for the chroot() for the process; the portion after the token will be the default directory for the process.
Note that this will override any configured DefaultRoot and DefaultChdir directives.
This option is intended for use for sites which are migrating from old wuftpd-based installations.

NoGetgrouplist

On systems which support it, the getgrouplist(3) function can be used to get the group membership list of a user in a much faster way. However, use of this function can have strange interactions with NSS modules, depending on the NSS modules used (see Bug#3475). Use this option to disable use of the getgrouplist(3) function, e.g.:
```
        AuthUnixOptions NoGetgrouplist
```
This setting has no effect on systems which do not support the getgrouplist(3) function.

NoInitgroups

On systems which support it, the initgroups(3) function can be used to get the group membership list of a user in a much faster way. However, there are limits to the number of groups to which a user can belong, use of this function means that groups which exceed that limit will be silently ignored. Thus for sites which need users to belong to a large number of groups, use this option to disable the use of the initgroups(3) function, e.g.:
```
        AuthUnixOptions NoInitgroups
```
This setting has no effect on systems which do not support the initgroups(3) function.

PersistentPasswd

Syntax: PersistentPasswd on|off
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_auth_unix
Compatibility: 1.2.0

The PersistentPasswd directive controls how mod_auth_unix handles authentication, user/group lookups, and user/group to name mapping. If set to on, mod_auth_unix will attempt to open the system-wide /etc/passwd, /etc/group (and potentially /etc/shadow) files itself, holding them open even during a chroot()ed login. (Note that /etc/shadow is never held open, for security reasons).

On some platforms, you must turn this option on, as the libc functions are incapable of accessing these databases from inside of a chroot().

Note: NIS/NIS+ and NSS users will most likely want to disable this feature. Failure to disable this will make your NIS/NIS+ maps and NSS lookups not work! On certain systems, you may also need to use the --enable-autoshadow option in order to authenticate both users from NIS maps or NSS lookups, and local users.

Installation

The mod_auth_unix module is compiled by default.

Logging
The mod_auth_unix module supports trace logging, via the module-specific log channels:

auth.unix

Thus for trace logging, to aid in debugging, you would use the following in your proftpd.conf:

  TraceLog /path/to/ftpd/trace.log
  Trace auth.unix:20

This trace logging can generate large files; it is intended for debugging use only, and should be removed from any production configuration.

Frequently Asked Questions

Question: I found that only the first 8 characters of passwords are used! This is a security bug!
Answer: No, it is not.

The default Unix password hashing scheme uses the Data Encryption Standard (DES) algorithm. As per the crypt(3) man page, only the first 8 characters of the password are used. Thus this 8 character limitation comes from the underlying system authentication, not 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.

Later, other crypt(3) implementations were made which can also support algorithms such as MD5, or Blowfish. Some platforms support these enhanced versions of crypt(3), some do not.

Question: It appears that the handling of expired passwords by mod_auth_unix is wrong. Is this a bug?
Answer: Not really. Different implementations have implemented expired passwords differently. One particular implementation even has special values, e.g. for the date of last password change:

The value 0 has a special meaning, which is that the user should change her password the next time she will log in the system.

These special cases vary from implementation to implementation; in the end, it is better to use the mod_auth_pam module and a PAM configuration which can better handle password expiration according to your site's needs.

Question: I've added new user to my system (i.e. in the /etc/passwd file), but my proftpd does not see the new user until I have restarted it. Is there any way to not have to restart proftpd, to disable its caching of system users?
Answer: ProFTPD is not caching system users, per se. Instead, this behavior is a side-effect of the PersistentPasswd setting. Check to see if you have:

  PersistentPasswd on

in your proftpd.conf. If you do (or if you do not have PersistentPasswd in your config at all), then change your proftpd.conf to have:

  PersistentPasswd off

Why is this necessary? When you use PersistentPasswd on, then proftpd will open a file descriptor on the system /etc/passwd file during server startup. This descriptor is kept open during the lifetime of the daemon. Later, when you add a new user to the system /etc/passwd file, the system tools create a new version of that file, then rename the new file to have the /etc/passwd name. But proftpd still has a descriptor to the old file, and does not see/know that the file has changed. That is why it can look like proftpd is "caching" your system users.

Question: I recently deleted a user's password using:

  $ passwd -d user

This successfully prevented the user from logging in via ssh, but they were able to successfully login using proftpd. This is a bug, right?
Answer: No, not really. It's more of a nasty gotcha.

Per the passwd(1) man page, the -d option does not do what you might assume/think it does:

  -d
  This is a quick way to delete a password for an account. It will set
  the named account passwordless. Available to root only.

Thus the -d option only deletes the password; it does not lock the account by setting a password of "*", and it does not delete the account/entry. Rather than using passwd -d, I would strongly recommend using passwd -l (to lock the account), or userdel(8) or equivalent (to remove the account entirely).

The issue then is that proftpd does not require that clients provide non-empty passwords by default. Thus a client providing an empty string as the password for a so-called "deleted" account would be able to successfully log in. To address this, there is the AllowEmptyPasswords directive. For example, setting this in your proftpd.conf should make using passwd -d work as you'd expect:

  <Global>
    AllowEmptyPassword off
  </Global>