[Comm] Question on FTP

[Headlong John]

> > Ну то есть вы хотите сказать, что об FTP теперь можно вообще забыть и всегда использовать только SMB? Вы хотите сказать, что все владельцы FTP-сайтов и веб-хостингов в интернете не очень хорошо разбираются в средствах доступа к файлам по сети?
> Да. Вы хотите об этом поговорить?

Да, конечно, я хочу узнать подробности. Просветите, пожалуйста. Почему для интернет-доступа к файлам все используют именно FTP, а не SMB, если он так хорош, как вы говорите.

> > Если бы мне нравился SMB или я хотел его использовать, я бы поставил MS Windows, а не открытую ОС.
> Не говорите глупостей. SMB придумали не в MS,

По данным, которые я смог узнать в интернете, этот протокол придумали в IBM, но к его последующему развитию имеет непосредственное отношение прежде всего MS, а не кто-то другой:

SMB was originally invented by Barry Feigenbaum at IBM to turn DOS "Interrupt 33" local file access into a networked file system, but the most common version is modified heavily by Microsoft. Microsoft merged the SMB protocol with the LAN Manager product they had been developing with 3Com, and continued to add features to the protocol in Windows for Workgroups and later versions of Windows.

SMB was originally designed to run on top of the NetBIOS protocol (which itself is typically run on NetBEUI, IPX/SPX or NBT), though SMB can also run on top of TCP/IP directly, since Windows 2000.

Источник: http://en.wikipedia.org/wiki/Server_Message_Block

Я могу ошибаться, но SMB у меня и у тех, кого я знаю, ассоциируется именно в MS Windows, а не с чем-то иным. Что касается Samba - то, как сказано в Wiki:

Because of the importance of the SMB protocol in interacting with the dominant Microsoft Windows platform, coupled with the heavily modified nature of the SMB implementation present in that platform, the Samba project was created to provide a free implementation of a compatible SMB client and server for use with non-Microsoft operating systems.

> этот протокол не является
> их собственностью, и если где-то существует реализация _стандарта_ (то
> есть открытой спецификации) на SMB, то уж никак не в Weendooze.

А чьей собственностью он является? IBM? Я не видел опубликованного ОФИЦИАЛЬНОГО стандарта на SMB. Если он у вас есть, дайте, пожалуйста, ссылку на открытый источник. Спасибо заранее.

> Просто
> если обсуждать сетевые файловые системы (а говоря о правах доступа к
> файлам, мы говорим о файловых системах) и делать выбор между NFS и SMB в
> _гетерогенных_ сетях, NFS резко проигрывает бедностью реализаций на
> не-POSIX системах. И остаётся SMB.

NFS, в отличие от SMB, - это интернет-стандарт и стандарт для Unix-систем (поправьте меня, если я ошибаюсь). Это разработка Sun, которую они сделали открытой, на этот протокол есть RFC и он поддерживается в любой Unix-системе. А есть ли RFC на SMB? Я не нашел такого в RFC index. Если я что-то просмотрел, подскажите номер RFC на SMB, пожалуйста. Спасибо заранее.

> > Для решения этой проблемы есть SSL, если безопасность критична.
> FTP-соединение, в силу специфики протокола, нельзя организовать
> поверх SSL. Требуется модифицировать протокол, что, конечно,
> поддерживается далеко не всеми. Обычно используется TLS, это проще. Есть
> несколько клиентов под linux, поддерживающих FTP/TLS. Наверное, есть они
> и для windows, сам не видел ничего, кроме lftp/CYGWIN или wget/CYGWIN (если
> пересобрать их с OpenSSL). Тут встаёт большая проблема принудительного
FBG> внедрения и обязательной перенасстройки именно этого ПО на клиентских
> машинах. Потому что без внедрения и настройки у вас будет сразу две
> радости: и пароли будут утекать, и пользователи не смогут зайти по FTP
> :)).

Ну у меня уже сейчас без внедрения и настройки клиенты на Windows и на Linux могут через FTP работать с моим сервером внутри нашей сети. Что касается SSL, то, насколько я помню, в MS IIS можно было организовать доступ к FTP-сайту через SSL, это делалось нажатием пары кнопок. При этом это не требовало какой-то особой модификации клиентского ПО. В Unix это невозможно?

> > А насколько "защищен" SMB?
> SMB вообще не гоняет по сети пароли, только невосстановимые хеши,

Про "невосстановимые" хеши, которые MS Windows хранит, например, для паролей пользователей, уже немало написано в интернете. Вот несколько ссылок:

http://www.uinc.ru/articles/29/index.shtml
http://old.osp.ru/win2000/2006/03/032.htm

> > Спасибо, эта часть проблемы уже решена, я писал об этом. Я использую /etc/fstab для монтирования, никаких самоделок.
> Самоделки понадобятся для модифицирования fstab при множественном
> добавлении пользоватлей и включения их в разнообразные группы..

Мне это не нужно. Я хочу собрать виртуальное FTP-дерево, а правами  доступа на уровне файловой системы ОС управлять. Так что fstab будет в полном порядке - модифицировал один раз и все.

> > Теперь такой вопрос - как в /etc/vsftpd.conf указать, куда chroot'ить
> > пользователей? Поскольку мне надо контролировать доступ к файлам на
> > уровне пользователей, то от виртуальных пользователей vsftpd я
> > отказался, буду использовать реальных. Но вот загвоздка: chroot'ятся
> > они в свои домашние каталоги, а мне надо, чтобы при доступе через ftp
> > они все chroot'ились в один и тот же каталог /home/ftpsite, который
> > будет набит точками монтирования нужных мне для ftp-доступа фрагментов
> > файловой системы. При этом надо, чтобы при обычном входе в систему
> > (через ssh, например), пользователь попадал в свой обычный домашний
> > каталог.
> Отменить chroot по пользователям вообще, а chroot-ить сам демон?

О, спасибо. Как-то об этом не подумал. Буду пробовать.

> > И еще - в чем скрытый смысл опции passwd_chroot_enable? Ведь при включенной chroot_local_user пользователи и так chroot'ятся в свои домашние каталоги, прописанные в /etc/passwd... Или я чего-то недопонял?
> Темна вода в облацех. Проще всего попробовать и посмотреть, что
> получится. Из невнятного текста man у меня создалось впечатление, что
> chroot_local_user -- это как раз то, что вам нужно. Гм. С добавлением
> 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.

Вот-вот, документация не совсем понятна в этом месте. Я думаю попробовать chroot'ить сам процесс. Спасибо.