Quote:
Originally Posted by WideloaD
is it better to have this than not have this set?
|
In short:
yes but.
* Yes because even if FTP credentials would be leeched (not that uncommon for users running A Certain Other OS) it would not grant the user rights to perform system recon.
Quote:
Originally Posted by WideloaD
I trust my users and the passwords are strong.
|
In turn I say
there is no compelling reason to trust unprivileged users by default.
* Yes
but be aware chrooting is part of system security
but does not constitute system hardening, there's more required.
* Yes
but be aware it does not prevent a user uploading any file and having Perl or PHP execute it. Examples: running scripts involving .htaccess modification, loading crontabs, MySQL injection, local or remote file inclusion and such due to running vulnerable applications or plugins in the web application stack. That's why keeping up to date, auditing and proper system hardening are important.
Quote:
Originally Posted by WideloaD
And... Is it better to use the "chroot_list_enable" rather than the blanket "chroot_local_user"?
|
It's the choice of chrooting
all users versus chrooting
a list of users. A choice for the first option obviously ensures everyone is automagically chrooted so no newly added account need to be added to any list.
Quote:
Originally Posted by WideloaD
In the face of this I would much rather have a list that says "ONLY ALLOW THE FOLLOWING USERS TO FTP IN".
|
Using Vsftpd with a PAM stack you can use the listfile module to create a list of allowed local user accounts.