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

## PersistentPasswd

Syntax: PersistentPasswd on|off
Default: None
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()`. At compile-time, the `configure` script will attempt to detect whether or not you need this support, and set the default accordingly.. However, such "guessing" may fail, and you will have to manually enable/disable the feature. If you cannot see user or group names when performing a directory listing inside a `chroot()`ed login, this indicates you must enable the directive. Use of the `AuthUserFile` or `AuthGroupFile` directives will force partial support for persistent user or group database files, regardless of `PersistentPasswd`'s setting.

Note: `NIS`/`NIS+` and `NSS` users will most likely want to disable this feature, regardless of `proftpd`'s detected configuration defaults. Failure to disable this will make your `NIS`/`NIS+` maps and `NSS` lookups not work! On certain systems, you may also need to 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.

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

Author: $Author: castaglia $
Last Updated: $Date: 2012/04/23 16:49:25 $

© Copyright 2010-2012
All Rights Reserved