Oui. Sans doute en utilisant :

chroot_local_user=YES

C'est une conséquence du fonctionnement de la sécurité de chroot() . Comme alternative, voir les liens en dur, ou le puissant

USER@MACHINE:~$ mount --bind

Oui, indirectement. vsftpd est un service basé sur inetd. Si vous utilisez le populaire “xinetd” la “xinetd” populaire comme inetd, il supporte les limites de connexion par service ou par IP. Il y a un exemple dans le répertoire “EXAMPLE”.

Si vous exécutez vsftpd en mode “standalone” avec le réglage

listen=YES

, alors vous disposez du réglage (par ex.) :

max_clients=10

vsftpd se protège contre les configurations dangereuses. La cause de ce message est généralement une appartenance douteuse du répertoire home du ftp. Le répertoire home ne doit PAS être possédé par l'utilisateur ftp lui-même. Il ne doit pas non plus être accessible en écriture par l'utilisateur ftp. Une façon de résoudre ce problème est :

USER@MACHINE:~$ chown root ~ftp; chmod -w ~ftp

Une autre cause pourrait être un essai d'utiliser chroot_local_user sans avoir réglé correctement le propriétaire du répertoire.

Le plus probable est que l'utilisateur configuré pour le paramètre “nopriv_user” (souvent “nobody”) n'existe pas sur votre système. vsftpd nécessite cet utilisateur pour exécuter des éléments sans privilèges.

Plusieurs problèmes peuvent se poser.

Par défaut, vsftpd désactive toutes les connexions autres que les connexions anonymes. Mettez local_enable=YES dans votre fichier /etc/vsftpd.conf pour permettre aux utilisateurs locaux de se connecter.

vsftpd essaie de se lier à PAM. (Exécutez “ldd vsftpd” et recherchez libpam pour savoir si c'est le cas ou non). Si vsftpd se lie à PAM, vous devrez alors installer un fichier PAM pour le service vsftpd. Un exemple de fichier pour les systèmes RedHat est inclus dans le répertoire “RedHat” - placez-le sous /etc/pam.d

Si vsftpd n'est pas lié à PAM, il y a plusieurs problèmes possibles. Le shell de l'utilisateur se trouve-t-il dans /etc/shells ? Si les mots de passe sont masqués, votre système a-t-il un fichier “shadow.h” dans le chemin include ?

Si vous n'utilisez pas PAM, vsftpd vérifiera lui-même si le shell de l'utilisateur est valide dans /etc/shells. Vous devrez peut-être désactiver cette vérification si vous utilisez un shell invalide pour désactiver les connexions autres que les connexions FTP. Mettez check_shell=NO dans votre fichier /etc/vsftpd.conf.

Par défaut, les commandes d'écriture, y compris les téléchargements et les nouveaux répertoires, sont désactivées. C'est une mesure de sécurité. Pour activer les écritures, mettez write_enable=YES dans votre fichier /etc/vsftpd.conf.

Notez tout d'abord que d'autres démons FTP ont les mêmes conséquences. C'est un problème générique. Ce problème n'est pas très grave, il est le suivant : Certaines personnes ont des comptes d'utilisateurs FTP qui ne sont pas autorisés à avoir un accès complet à l'interpréteur de commandes. Si ces comptes peuvent également télécharger des fichiers, il y a un léger risque. Un mauvais utilisateur a maintenant le contrôle de la racine du système de fichiers, qui est son répertoire personnel. Le démon FTP peut entraîner la lecture d'un fichier de configuration - par exemple /etc/some_file. Avec chroot(), ce fichier est maintenant sous le contrôle de l'utilisateur. vsftpd est prudent dans ce domaine. Mais la librairie du système peut vouloir ouvrir les fichiers de configuration des paramètres linguistiques ou d'autres paramètres…

Selon que l'envoi est effectué par un utilisateur local ou anonyme, utilisez “local_umask” ou “anon_umask” pour modifier ce paramètre. Par exemple, utilisez “anon_umask=022” pour donner aux fichiers téléchargés anonymement les permissions -rw-r–r–. Notez que le “0” avant le “22” est important.

Voir aussi la page de manuel vsftpd.conf.5 pour le nouveau paramètre “file_open_mode”.

Utilisez l'intégration PAM de vsftpd pour ce faire, et demandez à PAM de s'authentifier auprès d'un référentiel LDAP.

Oui. En intégrant vsftpd à xinetd, vous pouvez utiliser xinetd pour vous lier à plusieurs adresses IP différentes. Pour chaque adresse IP, xinetd doit lancer vsftpd avec un fichier de configuration différent. De cette manière, vous pouvez obtenir un comportement différent pour chaque adresse virtuelle.

Vous pouvez également exécuter autant de copies de vsftpd que nécessaire, en mode autonome. Utilisez “listen_address=x.x.x.x” pour définir l'IP virtuelle.

Oui, via l'intégration PAM. Définissez “guest_enable=YES” dans /etc/vsftpd.conf. Cela a pour effet de faire correspondre chaque connexion réussie non anonyme au nom d'utilisateur local spécifié dans “guest_username”. Ensuite, utilisez PAM et (par exemple) son module pam_userdb pour fournir une authentification par rapport à un référentiel externe (c'est-à-dire non-etc/passwd) d'utilisateurs. Note - il existe actuellement une restriction qui fait que lorsque guest_enable est activé, les utilisateurs locaux sont également mappés sur guest_username. Il existe un exemple de configuration d'utilisateurs virtuels dans le répertoire “EXAMPLE”.

Oui - d'une manière très puissante. Regardez le paramètre “user_config_dir” dans la page de manuel.

Oui, voir les paramètres de configuration “pasv_min_port” et “pasv_max_port”.

S'il s'agit d'une connexion anonyme, vérifiez que le répertoire personnel de l'utilisateur “ftp” est correct. Si vous utilisez le paramètre de configuration “anon_root”, vérifiez qu'il est également correct.

Ce comportement peut être modifié par le paramètre “use_localtime=YES”.

Oui. Certains paramètres individuels sont disponibles (par exemple, dirlist_enable) mais vous pouvez également spécifier un ensemble complet de commandes autorisées à l'aide de “cmds_allowed”.

Oui, si vous utilisez vsftpd en mode autonome, utilisez la directive “listen_port” dans vsftpd.conf.

Oui. Si vous exécutez vsftpd à partir d'un programme inetd ou xinetd, cela devient un problème inetd ou xinetd. Vous devez modifier les fichiers de configuration inetd ou xinetd (peut-être /etc/inetd.conf ou /etc/xinetd.d/vsftpd).

Yes. vsftpd uses PAM for authentication, so you need to configure PAM to use pam_ldap or pam_mysql modules. This may involve installing the PAM modules and then editing the PAM config file (perhaps /etc/pam.d/vsftpd).

Yes. If you are running vsftpd standalone, there is a “max_per_ip” setting.

Yes. If you are running vsftpd via xinetd, there is an xinetd config variable “per_source”.

Yes. See vsftpd.conf.5 man page and investigate settings such as “anon_max_rate” and “local_max_rate”.

Yes. vsftpd can integrate with tcp_wrappers (if built with this support). It is enabled with the setting “tcp_wrappers=YES”.

Yes. vsftpd can be run from xinetd, which supports tcp_wrappers integration.

Yes, as of version 1.2.0. Read the vsftpd.conf.5 man page.

Install the libcap package and retry the build. Seems to affect Debian users a lot.

Install the libcap-devel. This certainly affects Fedora.

This is affecting some RedHat users - some RedHat versions put the config file in /etc/vsftpd/vsftpd.conf.

Your system probably doesn't have IPv6 support. Either use a more modern system, use an older vsftpd (e.g. v1.1.3), or wait for a version of vsftpd without this problem!

vsftpd-1.2.1 should sort this out.

Yes. Look at the hide_file and deny_file options in the manual page.

Yes. An FTP server does not have to do anything special to support FXP. However, you many get tripped up by vsftpd's security precautions on IP addresses. In order to relax these precautions, have a look in the vsftpd.conf.5 for pasv_promiscuous (and the less advisable port_promiscuous).

You shouldn't see this with v1.2.1 or newer versions of vsftpd. Older versions of vsftpd can give this error if the user tries to download something from an unusual filesystem (e.g. FAT), which don't support performance features used by vsftpd. With vsftpd-1.1.3 and newer there is a config workaround, use_sendfile=NO.

This could be a bad interaction with glibc version 2.3 and PAM. A Debian user reported this. The initial report is here: http://lists.debian.org/debian-glibc/2003/debian-glibc-200309/msg00310.html

Yes, it does.

Large file support first appeared in v1.1.0.

Solaris large file support wasn't fixed until v1.2.2.

FreeBSD large file support wasn't fixed until v1.2.2.

The early Linux 2.6 kernels had a bug in this area - use v2.6.6 or newer.

Are you sure your FTP _client_ correctly supports large files?

A bug in this area is fixed in vsftpd v1.2.2. The problem has always existed but seems to frequently trigger only on certain platforms. For example, Fedora Core 1 - the suspected trigger is a glibc-2.3 platform, possibly in combination with a NPTL-enabled kernel.

Suspected bug with the Solaris / Veritas combination. With vsftpd-1.2.3 there is a possible workaround: no_log_lock=YES in your vsftpd.conf.5.

Yes, as of v2.0.0, this is supported for the control and data connections (hurrah). You need a build of vsftpd with this support enabled, and then you need to activate the ssl_enable setting. NOTE there are security considerations with this support. Please make sure to read the ssl_enable section in the vsftpd.conf.5 man page thoroughly before using.

FlashFXP is buggy - particularly with SSL transfers. Upgrade to v3.0RC4 or newer, which is reported to be fixed.

Yes, seems to be a problem with some RedHat setups. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111301 for details and suggested workarounds.

This is an issue with SELinux enabled distributions. The solution is to make sure the capability kernel module is loaded.

Seems to be a bug in ftp-tls, particularly with SSL transfers with bandwidth limiting in effect.

Most likely, your FTP client is in fact using the SSH protocol rather than the FTP protocol - so sshd is in control and not vsftpd!

Of course, make sure you turn on the chroot_local_user option!!

The version of gFTP on my Fedora Core 10 installation appears to send the “SIZE” command plain text during an SSL connection, which obviously breaks the SSL connection.

As of v2.1.0, vsftpd only accepts data connections that are reused sessions of the control connection. This is a security measure. Unfortunately, not all FTP clients reuse sessions (e.g. curl). You can disable this requirement by changing require_ssl_reuse to NO.

As of v2.2.0, the built-in sandboxing uses network isolation on Linux. This may be interfering with any module that needs to use the network to perform operations or lookups. Try changing isolate_network to NO.