В документации к 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). Мы на эти вещи идем когда клиент настаивает несмотря на предупреждение о риске и бессмысленности. ;-)