ProFTPD module mod_auth_unix

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

Author: $Author: castaglia $
Last Updated: $Date: 2011/02/20 18:20:26 $

© Copyright 2010-2011
All Rights Reserved