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

...@...:~$ 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 :

...@...:~$ 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.

The most likely cause of this is that the user that is configured as the 'nopriv_user' setting (often 'nobody') does not exist on your system. vsftpd needs this user to run bits of itself with no privilege.

There are various possible problems.

By default, vsftpd disables any logins other than anonymous logins. Put local_enable=YES in your /etc/vsftpd.conf to allow local users to log in.

vsftpd tries to link with PAM. (Run “ldd vsftpd” and look for libpam to find out whether this has happened or not). If vsftpd links with PAM, then you will need to have a PAM file installed for the vsftpd service. There is a sample one for RedHat systems included in the “RedHat” directory - put it under /etc/pam.d

If vsftpd didn't link with PAM, then there are various possible issues. Is the user's shell in /etc/shells? If you have shadowed passwords, does your system have a “shadow.h” file in the include path?

If you are not using PAM, then vsftpd will do its own check for a valid user shell in /etc/shells. You may need to disable this if you use an invalid shell to disable logins other than FTP logins. Put check_shell=NO in your /etc/vsftpd.conf.

By default, write commands, including uploads and new directories, are disabled. This is a security measure. To enable writes, put write_enable=YES in your /etc/vsftpd.conf.

Firstly note that other ftp daemons have the same implications. It is a generic problem. The problem isn't too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system's libc might want to open locale config files or other settings…

Depending on if this is an upload by a local user or an anonymous user, use “local_umask” or “anon_umask” to change this. For example, use “anon_umask=022” to give anonymously uploaded files permissions -rw-r–r–. Note that the “0” before the “22” is important.

Also see the vsftpd.conf.5 man page for the new “file_open_mode” parameter.

Use vsftpd's PAM integration to do this, and have PAM authenticate against an LDAP repository.

Yes. If you integrate vsftpd with xinetd, you can use xinetd to bind to several different IP addresses. For each IP address, get xinetd to launch vsftpd with a different config file. This way, you can get different behaviour per virtual address.

Alternatively, run as many copies as vsftpd as necessary, in standalone mode. Use “listen_address=x.x.x.x” to set the virtual IP.

Yes, via PAM integration. Set “guest_enable=YES” in /etc/vsftpd.conf. This has the effect of mapping every non-anonymous successful login to the local username specified in “guest_username”. Then, use PAM and (e.g.) its pam_userdb module to provide authentication against an external (i.e. non-/etc/passwd) repository of users. Note - currently there is a restriction that with guest_enable enabled, local users also get mapped to guest_username. There is an example of virtual users setup in the “EXAMPLE” directory.

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

Yes. See the config settings “pasv_min_port” and “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.

This behaviour can be changed with the setting “use_localtime=YES”.

Yes. There are some individual settings (e.g. dirlist_enable) or you can specify a complete set of allowed commands with “cmds_allowed”.

Yes. If you are running vsftpd in standalone mode, use the “listen_port” directive in vsftpd.conf.

Yes. If you are running vsftpd from an inetd or xinetd program, this becomes an inetd or xinetd problem. You must change the inetd or xinetd configuration files (perhaps /etc/inetd.conf or /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.