Всё гораздо проще: chroot в пользовательские каталоги делать не следует, точка.В документации к vsftpd это отражено:
chroot_local_user
If set to YES, local users will be (by default) placed in a
chroot() jail in their home directory after login. Warning:
This option has security implications, especially if the users
have upload permission, or shell access. Only enable if you know
what you are doing. Note that these security implications are
not vsftpd specific. They apply to all FTP daemons which offer
to put local users in chroot() jails.
Default: NO
Альтернатива: для пользователя, который должен быть в chroot, но при этом иметь доступ на запись в свой домашний каталог, прописать путь к домашнему каталогу в /etc/passwd в виде: /home/user/./home/user (да, с "/./" внутри пути). На наружный /home/user выставить владельцем root, на /home/user/./home/user - user'а. При этом vsftpd с passwd_chroot_enable=YES будет делать chroot в наружный /home/user, в который у user'а записи нет, тогда как реальным домашним каталогом user'а является внутренний (после захода по FTP, будет виден как /home/user и текущий каталог). Вместо /home/user внутри можно использовать и один каталог - например, назвать его homedir - его имя должно быть выбрано таким, чтобы не оказаться частью одного из стандартных путей к чему-то, используемому системными библиотеками. (Вариант с повтором /home/user хорош тем, что /home по FHS предназначен именно для расположения в нем домашних каталогов, а какое-либо другое имя каталога в корневом каталоге мало ли что будет означать для системных библиотек в будущем.)
Правда, даже с такими настройками очень легко получить уязвимость если остальные настройки приведут к тому, что vsftpd будет делать chroot в домашний каталог не только для пользователей с явно указанным "/./". Тут надо внимательно смотреть все настройки и списки пользователей (у vsftpd есть несколько опций на эту тему).
Так что лучше таких chroot'ов не делать вообще, тем более что, как правило, смысла в них мало (например, если речь идет об обновлении контента динамического веб-сайта, включая скрипты, выполняемые сервером без chroot). Мы на эти вещи идем когда клиент настаивает несмотря на предупреждение о риске и бессмысленности. ;-)
