Jusqu'à présent, je n'ai pas pu garder un utilisateur FTP emprisonné dans le répertoire de leur site Web. Existe-t-il une solution qui corrige ce bogue et garde l'utilisateur emprisonné dans son répertoire?
Mes paramètres vsFTPd que j'ai modifiés:
listen_port=9000
Set: anonymous_enable=NO
Uncomment: local_enable=YES
Uncomment: write_enable=YES
Uncomment: local_umask=022
Set: connect_from_port_20=NO
Uncomment: idle_session_timeout=600
Uncomment: data_connection_timeout=120
Comment out: #ftpd_banner=Welcome to blah FTP service. [should be on line 104]
Added: banner_file=/etc/issue.net
Uncomment: chroot_local_user=YES
Uncomment: chroot_local_user=YES
Uncomment: chroot_list_enable=YES
Uncomment : chroot_list_file=/etc/vsftpd.chroot_list
À la fin du fichier, j'ai ajouté:
# Show hidden files and the "." and ".." folders.
# Useful to not write over hidden files:
force_dot_files=YES
# Hide the info about the owner (user and group) of the files.
hide_ids=YES
# Connection limit for each IP address:
max_per_ip=10
# Maximum number of clients:
max_clients=5
# FTP Passive Settings
pasv_enable=YES
#If your listen_port is 9000 set this range to 7500 and 8500
pasv_min_port=[port range min]
pasv_max_port=[port range max]
L'utilisateur en question mybloguser
,, est emprisonné dans le répertoire de son site Web sous /srv/www/myblog
et cet utilisateur ne fait pas partie du nano /etc/vsftpd.chroot_list
fichier. Le répertoire personnel de l'utilisateur est également celui /srv/www/myblog
qui fonctionnait auparavant.
J'ai essayé la allow_writeable_chroot=YES
solution qui n'a pas fonctionné et j'ai complètement cassé vsFTPd.
J'ai essayé:
Comment pouvons-nous à la fois corriger cette erreur et garder l'utilisateur emprisonné dans son répertoire personnel?
allow_writeable_chroot=YES
était suffisant et fonctionnait "comme prévu" FWIW ...