[Comm] Question on FTP

[Comm] Question on FTP

[Headlong John]

Здравствуйте.

У меня проблема возникла, не могу решить, не знаю, к кому обратиться и где
посмотреть информацию. Направьте меня, пожалуйста. Кратко опишу проблему.

У меня сервер под Линуксом для джава-разработок, дистрибутив ALT Master
2.4. Так вот, я хочу обеспечить разработчикам возможность самим деплоить
приложения на него не обладая при этом ни правами root'а ОС, ни правами
администратора сервера приложений (дает возможность, кроме деплоймента,
конфигурировать сервер приложений через веб или утилитами командной
строки). Для этого решил использовать возможность автоматического
деплоймента, когда собранные модули и приложения просто выкладываются в
определенный каталог. Решил использовать для этого FTP, чтобы не
привязываться к файловым службам, специфическим для ОС (nfs или smb).

При этом желательно сделать так, чтобы можно было ограничить возможность
перемещения пользователей FTP по файловой системе определенными участками,
а также сделать так, чтобы можно было права на проекты раздавать. Решил
использовать vsftpd из ALT Master 2.4. В результате не могу добиться того,
что мне нужно.

Сервер приложений установлен в /opt/SUNWappserver (это Sun Java System
Application Server 8.2). Сервер приложений поддерживает понятие доменов,
каждый домен, грубо говоря, - это совокупность настроек и продеплоенных
приложений. Каждый домен расположен в своем подкаталоге каталога
/opt/SUNWappserver/domains. Например, домен по умолчанию - в
/opt/SUNWappserver/domains/domain1. Для автоматического деплоймента
достаточно записать модуль или приложение в подкаталог autodeploy, можно в
распакованном виде (то есть в подкаталог проекта в каталоге autodeploy
нужного домена), что удобно с точки зрения обновления приложения и
управления доступом разных людей к разным проектам.

То есть в итоге должно получиться примерно следующее:

Домен domain1:

/opt/SUNWappserver/domains/domain1/autodeploy

Проекты в домене domain1:

каталог project1a - доступ у user1, user2
каталог project1b - доступ у user2, user3

Домен domain2:

/opt/SUNWappserver/domains/domain2/autodeploy

каталог project2a - доступ у user1, user3
каталог project2b - доступ у user4

Скажем, пользователь подключается по FTP, попадает в некий виртуальный
корневой каталог. Там, скажем, каталоги, соответствующие доменам сервера
приложений, а в них - каталоги проектов этого домена. Он может ходить
только по тем из этих каталогов и делать с ними только то, что разрешено
(на уровне файловой системы). При этом никаких других частей файловой
системы не должно быть доступно.

Так вот. Если использовать доступ под реальными пользователями, то
получается, что они могут гулять по всей файловой системе, зато можно
сделать симлинки на нужные каталоги из домашнего каталога. Если chroot'ить
их, то они будут ограничены своим домашним каталогом, а в нужные для
деплоймента каталоги не попадут никогда, и ALT Master не дает создавать
хардлинки на каталоги (у меня файловая система Ext2). chroot'ить их в
/opt/SUNWappserver/domains, естественно, я тоже не хочу, потому что мало
ли, может нужно будет предоставить по FTP доступ к какому-нибудь каталогу
за пределами ветви /opt/SUNWappserver/domains и чего?

Если использовать виртуальных пользователей, то ситуация аналогичная, но
еще ухудшается тем, что доступ к файловой системе все виртуальные
пользователи получают под одним и тем же пользователем ОС, что исключает
возможность ограничения доступа пользователей к проектам друг друга.

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

Подскажите, пожалуйста, куда смотреть, где читать, потому что документация
по vsftpd довольно скудная, тем более нет документации концептуального
характера.

Спасибо заранее.

Re: [Comm] Question on FTP

[Fr. Br. George]

On Fri, Sep 01, 2006 at 01:01:57PM +0400, Headlong John wrote:
> Здравствуйте.
> 
> У меня проблема возникла, не могу решить, не знаю, к кому обратиться и где
> посмотреть информацию. Направьте меня, пожалуйста. Кратко опишу проблему.
> 
> У меня сервер под Линуксом для джава-разработок, дистрибутив ALT Master
> Решил использовать для этого FTP, чтобы не
> привязываться к файловым службам, специфическим для ОС (nfs или smb).
А в чём разница? Так вы привязываетесь к FTP-клиентам для ОС. Думаю, smb
вполне подошло бы, да и проблем, описанных ниже, не возникло бы.
Обратите внимание, что своей схемой доступа к объектом вы хотите
смоделировать именно права доступа в стиле smb. Зачем изобретать новый
велосипед, когда можно освоить мотоцикл? Поддержка smb-клиентов в
ALM2.4 работает весьма неплохо. Samba -- весьма хорошо.

> При этом желательно сделать так, чтобы можно было ограничить возможность
> перемещения пользователей FTP по файловой системе определенными участками,
> а также сделать так, чтобы можно было права на проекты раздавать. Решил
> использовать vsftpd из ALT Master 2.4. В результате не могу добиться того,
> что мне нужно.
Возможностей vsftpd, видимо, недостаточно. Можно посмотреть в сторону
proftpd и его расширений. Если вам в самом деле хочется обойтись без
smb. И если вас будут удовлетворять гуляющие по вашей сети в открытом
виде ftp-пароли.

> Что я хочу. Я хочу собрать виртуальное дерево FTP-сервера на основе
> реальных каталогов, произвольно разбросанных по файловой системе, и
> управлять доступом к нему для пользователей. Я хочу, чтобы структура
> дерева каталогов FTP-сервера не была жестко привязана к структуре
> каталогов на диске.
Деталью этого велосипеда может быть многократный mount --bind, возможно,
управляемый sh-сценарием и какой-нибудь самодельной картой в стиле "кому
чего давать".

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Headlong John]

Hello, Fr. Br. George
Пн, 11.09.2006 13:55:19 you wrote:

FBG> On Fri, Sep 01, 2006 at 01:01:57PM +0400, Headlong John wrote:
> > Здравствуйте.
> > 
> > У меня проблема возникла, не могу решить, не знаю, к кому обратиться и где
> > посмотреть информацию. Направьте меня, пожалуйста. Кратко опишу проблему.
> > 
> > У меня сервер под Линуксом для джава-разработок, дистрибутив ALT Master
> > Решил использовать для этого FTP, чтобы не
> > привязываться к файловым службам, специфическим для ОС (nfs или smb).
> А в чём разница? Так вы привязываетесь к FTP-клиентам для ОС. Думаю, smb
> вполне подошло бы, да и проблем, описанных ниже, не возникло бы.
> Обратите внимание, что своей схемой доступа к объектом вы хотите
> смоделировать именно права доступа в стиле smb. Зачем изобретать новый
> велосипед, когда можно освоить мотоцикл? Поддержка smb-клиентов в
> ALM2.4 работает весьма неплохо. Samba -- весьма хорошо.

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

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

> > При этом желательно сделать так, чтобы можно было ограничить возможность
> > перемещения пользователей FTP по файловой системе определенными участками,
> > а также сделать так, чтобы можно было права на проекты раздавать. Решил
> > использовать vsftpd из ALT Master 2.4. В результате не могу добиться того,
> > что мне нужно.
> Возможностей vsftpd, видимо, недостаточно. Можно посмотреть в сторону
> proftpd и его расширений. Если вам в самом деле хочется обойтись без
> smb. И если вас будут удовлетворять гуляющие по вашей сети в открытом
> виде ftp-пароли.

Для решения этой проблемы есть SSL, если безопасность критична. А насколько "защищен" SMB?

> > Что я хочу. Я хочу собрать виртуальное дерево FTP-сервера на основе
> > реальных каталогов, произвольно разбросанных по файловой системе, и
> > управлять доступом к нему для пользователей. Я хочу, чтобы структура
> > дерева каталогов FTP-сервера не была жестко привязана к структуре
> > каталогов на диске.
> Деталью этого велосипеда может быть многократный mount --bind, возможно,
> управляемый sh-сценарием и какой-нибудь самодельной картой в стиле "кому
> чего давать".

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

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

И еще - в чем скрытый смысл опции passwd_chroot_enable? Ведь при включенной chroot_local_user пользователи и так chroot'ятся в свои домашние каталоги, прописанные в /etc/passwd... Или я чего-то недопонял?

Спасибо заранее.

Re: [Comm] Question on FTP

[Fr. Br. George]

On Tue, Sep 12, 2006 at 11:50:22AM +0400, Headlong John wrote:
> Ну то есть вы хотите сказать, что об FTP теперь можно вообще забыть и всегда использовать только SMB? Вы хотите сказать, что все владельцы FTP-сайтов и веб-хостингов в интернете не очень хорошо разбираются в средствах доступа к файлам по сети?
Да. Вы хотите об этом поговорить?

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

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

> А насколько "защищен" SMB?
SMB вообще не гоняет по сети пароли, только невосстановимые хеши,
которые при желании можно защитить SSL, хотя, кажется, незачем.
Правда, он хранит эти пароли в расшифровываемом виде на сервере. Так что
вопрос в том, насколько "защищён" сам сервер. Про NFS молчу: там
IP-based авторизация.

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

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [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'ить сам процесс. Спасибо.

Re: [Comm] Question on FTP

[Fr. Br. George]

On Wed, Sep 13, 2006 at 11:41:03AM +0400, Headlong John wrote:
> Да, конечно, я хочу узнать подробности. Просветите, пожалуйста. Почему для интернет-доступа к файлам все используют именно FTP, а не SMB, если он так хорош, как вы говорите.
Потому что "интернет-доступ к файлам" и "сетевая файловая система" --
совершенно разные вещи. Предоставлять хостерам доступ по SMB всего лишь
для выкладывания файлов -- стрельба из пушки по воробьям. А чем сложнее
протокол, тем больше глюков. Особено у клиентов по виндовзом. К тому же
на хостинге обычно очень трепетно относятся к вычислительным ресурсам.

Настолько трепетно, что предпочитают не сообщать пользователям. что
наиболее нетребовательный к вычислительным ресурсам протокол FTP по
совместительству и наиболее небезопасный: гоняет пароли в открытом виде.
Наверное, надеются на эффект неуловимого Джо.

> > > Если бы мне нравился SMB или я хотел его использовать, я бы поставил MS Windows, а не открытую ОС.
> > Не говорите глупостей. SMB придумали не в MS,
> 
> По данным, которые я смог узнать в интернете, этот протокол придумали в IBM, но к его последующему развитию имеет непосредственное отношение прежде всего MS, а не кто-то другой:
Да. Хотя сейчас это не совсем так: основной фронт разработки семейства
протоколов CIFS переехал в Samba, а в M$ регулярно обсуждают идею от
CIFS отказаться, так как слишком оно документировано.

> Я могу ошибаться, но SMB у меня и у тех, кого я знаю, ассоциируется именно в MS Windows, а не с чем-то иным. Что касается Samba - то, как сказано в Wiki:
Насчёт ваших собственных ассоциаций вы ошибаться не можете :). Если у
вас -- как и у меня -- вызывает раздражение всё, связанное с M$, то ведь
не потому, что "все они там -- уроды"?

Например, меня бесит многое от M$ по причине _полной_ невозможности понять,
что и как работает: никакой тех. документации, все help-ы -- для
секретарш, шаманство вместо отладки ошибок и мозговая чесотка от
отсутствия информации.

А Samba весьма прилично документирована. По крайней мене, на инженерном
и пользовательском уровне.

> > и если где-то существует реализация _стандарта_ (то
> > есть открытой спецификации) на SMB, то уж никак не в Weendooze.
> А чьей собственностью он является?
Публичной.
> Я не видел опубликованного ОФИЦИАЛЬНОГО стандарта на SMB.
Это да, "ОФИЦИАЛЬНОГО стандарта" нет. Вот в IETF M$-цы пытались
затолкать какой-то draft, но он был настолько мутный, что к 2002 году
просрочился.

Так что открытая информация берётся именно из http://devel.samba.org/
А в качестве неОФИЦИАЛЬНОГО стандарта -- http://www.snia.org/tech_activities/CIFS

Здесь я удалил кусок, в котором вы в ответ на утверждение "NFS в
виндовзе плохо поддерживается" вдруг сказали "за то он стандартный и
везде работает". BTW, NFSv4-сервер в Linux пока не доделали.

> Ну у меня уже сейчас без внедрения и настройки клиенты на Windows и на Linux могут через FTP работать с моим сервером внутри нашей сети.
Ну так вопрос лишь в том, опасна ли для вас утечка учётных записей.

> в MS IIS можно было организовать доступ к FTP-сайту через SSL, это делалось нажатием пары кнопок. При этом это не требовало какой-то особой модификации клиентского ПО.
Список клиентского ПО, в котором доступ по FTP/TLS работает совсем без
модификации:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html#client

Заодно и серверного. IIS там в единственном месте упомянут. Думаю, что
сказанное вами -- или легенда, или слух, или реклама M$ IIS :)

> > > А насколько "защищен" SMB?
> > SMB вообще не гоняет по сети пароли, только невосстановимые хеши,
> Про "невосстановимые" хеши, которые MS Windows хранит, например, для паролей пользователей, уже немало написано в интернете. Вот несколько ссылок:
Скорее всего вы неправильно прочли предыдущее предложение, а также то, в
котором было написано, что _сервер_ хранит вполне восстановимые пароли ;)

> http://www.uinc.ru/articles/29/index.shtml
"Даже если злоумышленник перехватит хеш, то при правильно выбранном
пароле узнать пароль будет невозможно (перебор всех комбинаций займет
длительный период). Кроме того, использование каждый раз при генерации
хеша в качестве входных данных случайные данные, защищает от повторного
использования перехваченного злоумышленником хеша, который может быть
получен при авторизации подлинного пользователя."

Остальной текст посвящён взлому виндовза с дискетки.

> http://old.osp.ru/win2000/2006/03/032.htm
Текст посвящён взлому LM-ключа. LM может быть и используется по у
молчанию в виндовзе до сих пор, но не в Sambba.

Знаете, меня очень интересует тема сетевой инфраструктуры Linux.
С ней не шибко ладно дело обстоит, что удивительно.
В частности, ни одной нормальной сетевой ФС с user-based авторизацией
просто нет. Чем IP-based авторизация -- вроде NFS -- хуже, знает любой,
кто делал "su - poorlamer; rm -rf /home/nfs_mounted/poorlamer".
Или _у кого_ это делали.

Вот и приходится изобретать странные поделки, вроде GnomeVFS/FTP или
FUSE/SshFS. Которые работают, но хорошей поддержки не имеют.

Или использовать Samba.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Headlong John]

В  общем, решил проблему так. Мой /etc/vsftd.conf:

anonymous_enable=NO
local_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
local_root=/var/ftp
chroot_local_user=YES
write_enable=YES

Мой /etc/xinetd.d/vsftpd:

service ftp
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        nice            = 10
        rlimit_as       = 16M
        server          = /usr/sbin/vsftpd
        only_from       = 192.168.0.0/24
}

Мой /etc/fstab:

...
# Это чтобы автоматически передеплоивать целиком приложение (ear) или модуль (war, ejb-jar)
/opt/SUNWappserver/domains/domain1/autodeploy /var/ftp/domain1/autodeploy none rw,bind 0 0

Права на домен назначил так:

[root@server-java john]# cd /var/ftp
[root@server-java ftp]# ls -la
total 3
drwxr-xr-x   3 root vsftpd 1024 Sep 14 16:50 .
drwxr-xr-x  21 root root   1024 Sep 14 16:48 ..
drwxr-xr-x   5 root vsftpd 1024 Sep 14 19:33 domain1

Для работы над проектом создаю группу, соответствующую имени проекта, например library, включаю туда пользователей-разработчиков проекта. Далее в каталоге домена создаю пустой файл, соответствующий имени файла приложения или модуля с проектом, и назначаю ему права, например для проекта library:

[root@server-java ftp]# cd domain1
[root@server-java domain1]# ls -la
total 3
drwxr-xr-x  3 root vsftpd  1024 Sep 14 21:51 .
drwxr-xr-x  5 root vsftpd  1024 Sep 14 19:33 ..
drwxr-xr-x  2 root root    1024 Sep 14 20:05 .autodeploystatus
-rw-rw----  1 root library    0 Sep 14 20:05 library.ear

После этого через FTP разработчики могут обновлять свои и только свои проекты. И они могут перемещаться только по той части файловой системы, которая расположена в /var/ftp с учетом примонтированных частей (после подключения они попадают в /var/ftp). Удалять и создавать проекты они не могут. В результате получил примерно то, что хотел :-)

Единственное, что не получилось сделать как я хотел, так это предоставить возможность работать с проектом в распакованном виде. Дело в том, что сервер приложений распаковывает продеплоенное приложение в подкаталог каталога /opt/SUNWappserver/domains/домен/applications/j2ee-apps, а продеплоенный модуль - в подкаталог каталога /opt/SUNWappserver/domains/домен/applications/j2ee-modules, имя которого соответствует имени приложения или модуля. Например, приложение library.ear будет распаковано в /opt/SUNWappserver/domains/домен/applications/j2ee-apps/library. Проблема же в том, что при передеплойменте этот каталог удаляется и создается заново и для него устанавливается владелец и права доступа в соответствии с глобальными настройками (у меня это root:root и 755 соответственно), учесть права доступа на уровне участников разных проектов тут не получается :-( Что же касается каталога /opt/SUNWappserver/domains/домен/autodeploy, то сюда можно записывать только приложения или модули в виде архивов ear или war, ejb-jar соответственно.

> У меня сервер под Линуксом для джава-разработок, дистрибутив ALT Master
> 2.4. Так вот, я хочу обеспечить разработчикам возможность самим деплоить
> приложения на него не обладая при этом ни правами root'а ОС, ни правами
> администратора сервера приложений (дает возможность, кроме деплоймента,
> конфигурировать сервер приложений через веб или утилитами командной
> строки). Для этого решил использовать возможность автоматического
> деплоймента, когда собранные модули и приложения просто выкладываются в
> определенный каталог. Решил использовать для этого FTP, чтобы не
> привязываться к файловым службам, специфическим для ОС (nfs или smb).
> 
> При этом желательно сделать так, чтобы можно было ограничить возможность
> перемещения пользователей FTP по файловой системе определенными участками,
> а также сделать так, чтобы можно было права на проекты раздавать. Решил
> использовать vsftpd из ALT Master 2.4. В результате не могу добиться того,
> что мне нужно.
> 
> Сервер приложений установлен в /opt/SUNWappserver (это Sun Java System
> Application Server 8.2). Сервер приложений поддерживает понятие доменов,
> каждый домен, грубо говоря, - это совокупность настроек и продеплоенных
> приложений. Каждый домен расположен в своем подкаталоге каталога
> /opt/SUNWappserver/domains. Например, домен по умолчанию - в
> /opt/SUNWappserver/domains/domain1. Для автоматического деплоймента
> достаточно записать модуль или приложение в подкаталог autodeploy, можно в
> распакованном виде (то есть в подкаталог проекта в каталоге autodeploy
> нужного домена), что удобно с точки зрения обновления приложения и
> управления доступом разных людей к разным проектам.
> 
> То есть в итоге должно получиться примерно следующее:
> 
> Домен domain1:
> 
> /opt/SUNWappserver/domains/domain1/autodeploy
> 
> Проекты в домене domain1:
> 
> каталог project1a - доступ у user1, user2
> каталог project1b - доступ у user2, user3
> 
> Домен domain2:
> 
> /opt/SUNWappserver/domains/domain2/autodeploy
> 
> каталог project2a - доступ у user1, user3
> каталог project2b - доступ у user4
> 
> Скажем, пользователь подключается по FTP, попадает в некий виртуальный
> корневой каталог. Там, скажем, каталоги, соответствующие доменам сервера
> приложений, а в них - каталоги проектов этого домена. Он может ходить
> только по тем из этих каталогов и делать с ними только то, что разрешено
> (на уровне файловой системы). При этом никаких других частей файловой
> системы не должно быть доступно.

Re: [Comm] Question on FTP

[Headlong John]

Hello, Fr. Br. George
Чт, 14.09.2006 18:10:08 you wrote:

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

Ну вот мне, в принципе, тоже надо, чтобы люди имели возможность выкладывать файлы... Но только те люди и в те места, куда я им разрешу... Мне нужен FTP или SMB?

> А чем сложнее
> протокол, тем больше глюков. Особено у клиентов по виндовзом. К тому же
> на хостинге обычно очень трепетно относятся к вычислительным ресурсам.

С этим согласен.

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

Может быть :-)

> > По данным, которые я смог узнать в интернете, этот протокол придумали в IBM, но к его последующему развитию имеет непосредственное отношение прежде всего MS, а не кто-то другой:
> Да. Хотя сейчас это не совсем так: основной фронт разработки семейства
> протоколов CIFS переехал в Samba, а в M$ регулярно обсуждают идею от
> CIFS отказаться, так как слишком оно документировано.

Понятно, спасибо. Не знал этого.

> > Я могу ошибаться, но SMB у меня и у тех, кого я знаю, ассоциируется именно в MS Windows, а не с чем-то иным. Что касается Samba - то, как сказано в Wiki:
> Насчёт ваших собственных ассоциаций вы ошибаться не можете :). Если у
> вас -- как и у меня -- вызывает раздражение всё, связанное с M$, то ведь
> не потому, что "все они там -- уроды"?

Ну конечно не поэтому :-)

> Например, меня бесит многое от M$ по причине _полной_ невозможности понять,
> что и как работает: никакой тех. документации, все help-ы -- для
> секретарш, шаманство вместо отладки ошибок и мозговая чесотка от
> отсутствия информации.

О, вы так интеллигентно высказали то, о чем я обычно ору матом на все здание :-) Супер. Особенно про чесотку понравилось :-) Классно.

> А Samba весьма прилично документирована. По крайней мене, на инженерном
> и пользовательском уровне.

Да, меня в Unix-системах изначально привлекает именно это. Мне нравятся вещи, которые я могу изучать систематически и самостоятельно.

> > Я не видел опубликованного ОФИЦИАЛЬНОГО стандарта на SMB.
> Это да, "ОФИЦИАЛЬНОГО стандарта" нет. Вот в IETF M$-цы пытались
> затолкать какой-то draft, но он был настолько мутный, что к 2002 году
> просрочился.
> 
> Так что открытая информация берётся именно из http://devel.samba.org/
> А в качестве неОФИЦИАЛЬНОГО стандарта -- http://www.snia.org/tech_activities/CIFS

Спасибо!

> > Ну у меня уже сейчас без внедрения и настройки клиенты на Windows и на Linux могут через FTP работать с моим сервером внутри нашей сети.
> Ну так вопрос лишь в том, опасна ли для вас утечка учётных записей.

Да, сейчас вот у меня люди получают доступ внутри локальной сети предприятия. Чтобы перехватить пароль необходимо перехватить пакеты, передаваемые от клиента серверу. Это означает, что либо пакеты должны ретранслироваться коммутатором на все порты, либо сервер или клиенты должны быть поражены злоумышленником. Но сейчас коммутаторы типа switching hub, они вроде не должны на все порты информацию дублировать?

Если будет доступ через интернет, то, соответственно, пароль может быть перехвачен в случае поражения промежуточных шлюзов/маршрутизаторов, через которые проходят пакеты от клиента к серверу.

Что касается поражения сервера или клиента, то здесь, наверное, уже не имеет смысла вопрос о том, защищен протокол или нет. Я все правильно понимаю?

> > в MS IIS можно было организовать доступ к FTP-сайту через SSL, это делалось нажатием пары кнопок. При этом это не требовало какой-то особой модификации клиентского ПО.
> Список клиентского ПО, в котором доступ по FTP/TLS работает совсем без
> модификации:
> http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html#client
> 
> Заодно и серверного. IIS там в единственном месте упомянут. Думаю, что
> сказанное вами -- или легенда, или слух, или реклама M$ IIS :)

Про MS IIS - проверю еще раз в понедельник, напишу.

> > Про "невосстановимые" хеши, которые MS Windows хранит, например, для паролей пользователей, уже немало написано в интернете. Вот несколько ссылок:
> Скорее всего вы неправильно прочли предыдущее предложение, а также то, в
> котором было написано, что _сервер_ хранит вполне восстановимые пароли ;)
> 
> > http://www.uinc.ru/articles/29/index.shtml
> "Даже если злоумышленник перехватит хеш, то при правильно выбранном
> пароле узнать пароль будет невозможно (перебор всех комбинаций займет
> длительный период). Кроме того, использование каждый раз при генерации
> хеша в качестве входных данных случайные данные, защищает от повторного
> использования перехваченного злоумышленником хеша, который может быть
> получен при авторизации подлинного пользователя."
> 
> Остальной текст посвящён взлому виндовза с дискетки.

Насколько "правильным" должен быть пароль?

> > http://old.osp.ru/win2000/2006/03/032.htm
FBG> Текст посвящён взлому LM-ключа. LM может быть и используется по у
> молчанию в виндовзе до сих пор, но не в Sambba.

Да, я понял. Спасибо.

> Знаете, меня очень интересует тема сетевой инфраструктуры Linux.

Меня тоже :-)

> С ней не шибко ладно дело обстоит, что удивительно.
> В частности, ни одной нормальной сетевой ФС с user-based авторизацией
> просто нет.

А как же Samba?

Спасибо заранее.

Re: [Comm] Question on FTP

[Serge Polkovnikov]

Friday 15 September 2006 17:56, Headlong John написав:
>  Но сейчас коммутаторы типа switching hub, они вроде не должны на все порты
> информацию дублировать?

Не должны. Но обмануть их, к сожалению, можно. И обманывают (думаю любой 
современный снифер может это проделать). 
-- 
С уважением,
Сергей Полковников

Re: [Comm] Question on FTP

[Maxim Tyurin]

Serge Polkovnikov writes:

> Friday 15 September 2006 17:56, Headlong John написав:
>>  Но сейчас коммутаторы типа switching hub, они вроде не должны на все порты
>> информацию дублировать?
>
> Не должны. Но обмануть их, к сожалению, можно. И обманывают (думаю любой 
> современный снифер может это проделать). 

К сожалению да.
Как раз фортунка в тему :)
mrkooll ~ >  fortune -m перенаправить    (mrkooll@mrkooll.tdr.pibhe.com)[20:54:33]1|0.18
(ALT)
%
> А Вы сможете перехватить трафик на свитчах?
Легко. И не только перехватить, но и перенаправить.
У нас в Сизифе есть инструментарий для этого. Больше не скажу.
                -- ldv in sisyphus@
%

-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Question on FTP

[Michael Shigorin]

On Fri, Sep 15, 2006 at 06:56:06PM +0400, Headlong John wrote:
> Ну вот мне, в принципе, тоже надо, чтобы люди имели возможность
> выкладывать файлы... Но только те люди и в те места, куда я им
> разрешу... Мне нужен FTP или SMB?

Вы можете пример привести и типы клиентов?  Возможно, SMB+NFS
будет лучше, чем FTP.

> > Да. Хотя сейчас это не совсем так: основной фронт разработки
> > семейства протоколов CIFS переехал в Samba, а в M$ регулярно
> > обсуждают идею от CIFS отказаться, так как слишком оно
> > документировано.
> Понятно, спасибо. Не знал этого.

Насколько помню один рассказ, всё куда веселее -- из MS ушёл
человек, который собственно держал тамошний SMB-стек в голове
(и оставил массу недокументированного кода, в котором, судя по
прецедентам, за год разобраться даже при очень большом желании
может оказаться невозможно).  С другой стороны их давит Samba.
Выход логичен -- надо устроить новый lock-in.  Другой.

PS: наверное, общему трёпу типа этих слухов место в
smoke-room@...

> > Ну так вопрос лишь в том, опасна ли для вас утечка учётных записей.
> Да, сейчас вот у меня люди получают доступ внутри локальной
> сети предприятия. Чтобы перехватить пароль необходимо
> перехватить пакеты, передаваемые от клиента серверу. Это
> означает, что либо пакеты должны ретранслироваться коммутатором
> на все порты, либо сервер или клиенты должны быть поражены
> злоумышленником. Но сейчас коммутаторы типа switching hub, они
> вроде не должны на все порты информацию дублировать?

Строго говоря, могут -- если зафлудить специальным образом 
и переполнить MAC cache.

> > Знаете, меня очень интересует тема сетевой инфраструктуры Linux.
> Меня тоже :-)

Дядьки, а перебирайтесь-ка с админскими вопросами в sysadmins@?
Оно как бы для более вдумчивых обсуждений с конфигами и прочим
контекстом и предназначалось, насколько понимаю и вижу.

(возникло после очередного широкого обсуждения настройки postfix 
здеся :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Question on FTP

[Alexandr A. Alexandrov]

Доброго времени суток!

Headlong John пишет:

> > Да, сейчас вот у меня люди получают доступ внутри локальной сети
предприятия. Чтобы перехватить пароль необходимо перехватить пакеты,
передаваемые от клиента серверу. Это означает, что либо пакеты должны
ретранслироваться коммутатором на все порты, либо сервер или клиенты
должны быть поражены злоумышленником. Но сейчас коммутаторы типа
switching hub, они вроде не должны на все порты информацию дублировать?
> >

  Они-то не должны. Но вот если у тебя в сети не отслеживаются атаки на
ARP с перенаправлением/дублированием - любой современный сниффер с этим
справится. Не могу, правда, сказать, насколько успешно это будет при
большом количестве свичей (сложной топологии сети) - но в простых
случаях лично убеждался в этом...

-- С уважением, ААА. Девиз дня: Даже у самого плохого человека можно
найти что-то хоpошее, если его тщательно обыскать

Re: [Comm] Question on FTP

[Fr. Br. George]

On Fri, Sep 15, 2006 at 06:56:06PM +0400, Headlong John wrote:
> Да, сейчас вот у меня люди получают доступ внутри локальной сети предприятия. Чтобы перехватить пароль необходимо перехватить пакеты, передаваемые от клиента серверу. Это означает, что либо пакеты должны ретранслироваться коммутатором на все порты, либо сервер или клиенты должны быть поражены злоумышленником. Но сейчас коммутаторы типа switching hub, они вроде не должны на все порты информацию дублировать?
Теоретически switching hub тоже подвержены атакам, например,
переполнения MAC-таблиц, отчего они либо затыкаются, либо превращаются в
ретранслирующие hub-ы. Кроме того, есть проблема hub-ов второго уровняЖ
кто их знет, фильтрующие ли они, т. е. нет ли рядом с сервером и в
особенности -- с клиентом -- компьютера, который спокойно сканирует все
пакеты соседа?

> Если будет доступ через интернет, то, соответственно, пароль может быть перехвачен в случае поражения промежуточных шлюзов/маршрутизаторов, через которые проходят пакеты от клиента к серверу.
Это вдобавок к предыдущему -- ведь теперь уже никто не сможет
гарантировать неутечку учётной записи на _клиентской_ стороне, кроме
самого клиента. А клиенты требуют гарантий от поставщика услуг.

> Что касается поражения сервера или клиента, то здесь, наверное, уже не имеет смысла вопрос о том, защищен протокол или нет. Я все правильно понимаю?
Да, но это как раз наименее вероятное при грамотном администрировании
событие.

> Насколько "правильным" должен быть пароль?
Любой, не подверженный переборным атакам. ALT Linux-овский (OWL-ский) в
стиле pam_qc вполне подойдёт.

> > С ней не шибко ладно дело обстоит, что удивительно.
> > В частности, ни одной нормальной сетевой ФС с user-based авторизацией
> > просто нет.
> А как же Samba?
Главный недостаток Samba -- невозможность испльзования её для
идентификации и авторизации в стиле pam (pam_winbind -- это просто фильм
ужасов какой-то). Это значит, что или _вся_ инфраструктура должна
строиться на Samba, или Samba останется _сторонней_ системой. Тогда для
доступа к ней придётся либо обучать пользователя запуску smbclient, либо
городить какие-то навигаторы в стиле винодвз, либо изобретать громоздкие
велосипеды с автомонтированием в .profile или ещё как. Последнее может
претендовать на включение в инфраструктуру, но случаи полной и удобной
реализации мне неизвестны.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Fr. Br. George]

On Fri, Sep 15, 2006 at 06:56:06PM +0400, Headlong John wrote:
> Ну вот мне, в принципе, тоже надо, чтобы люди имели возможность выкладывать файлы... Но только те люди и в те места, куда я им разрешу... Мне нужен FTP или SMB?
По идее -- scp. Точнее, SFTP. Клиент под windows -- winscp. Вменяемые
хостеры именно так делают.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Fr. Br. George]

On Sat, Sep 16, 2006 at 11:54:36AM +0300, Michael Shigorin wrote:
> > > Знаете, меня очень интересует тема сетевой инфраструктуры Linux.
> > Меня тоже :-)
> 
> Дядьки, а перебирайтесь-ка с админскими вопросами в sysadmins@?
> Оно как бы для более вдумчивых обсуждений с конфигами и прочим
> контекстом и предназначалось, насколько понимаю и вижу.
Обсуждать пустое место с его конфигами и прочим контекстом?
Нет, это тоже в курилку.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Michael Shigorin]

On Mon, Sep 18, 2006 at 02:09:55PM +0400, Fr. Br. George wrote:
> > > С ней не шибко ладно дело обстоит, что удивительно.  В
> > > частности, ни одной нормальной сетевой ФС с user-based
> > > авторизацией просто нет.
> > А как же Samba?
> Главный недостаток Samba -- невозможность испльзования её для
> идентификации и авторизации в стиле pam (pam_winbind -- это
> просто фильм ужасов какой-то). Это значит, что или _вся_
> инфраструктура должна строиться на Samba, или Samba останется
> _сторонней_ системой.

Или кое-кто всё-таки почитает про LDAP.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Question on FTP

[Fr. Br. George]

On Mon, Sep 18, 2006 at 02:38:32PM +0300, Michael Shigorin wrote:
> Или кое-кто всё-таки почитает про LDAP.
Не морочь людям мозги.

Для начала. LDAP никак не влияет на "пограничность" Samba и её
протоколов.

LDAP -- это backend, и тогда читай-не читай, без разницы, где ты хранишь
учётную информацию, хоть в файлах, хоть MySQL. Ни лучше, ни хуже не
будет.

Либо же LDAP -- это _механизм_, то есть хрень, с которой надо
пересобрать все приложения, что ты планируешь использовать в production
(некоторые из них действительно поддерживают LDAP, каждая по собственной
схеме). 

В любом случае добавится ещё проблема синхронизации одинаковых полей,
которые в разных схемах названы по-разному, а также зависящих друг от
друга полей, типа smb-пароля и pam-хеша. Эта проблема непростая, но
решаемая, только мне неизветсны факты её решения не на коленке. Если
есть ссылочка -- поделись.

Плюс, разумеется, ежедневное администрирование OpenLDAP (есть работающие
и проверенные альтернативы?), в случае зависния/отказа которого (что
бывает) виснут и все авторизационные механизмы всех клиентов, а иногда и
база приходит в нерабочее состояние.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

P.S.	Не хочу поднимать тему про LDAP до тех пор, пока в Сизифе не
	возникнет дистрибутивного "решения". Или хотя бы человека,
	который покажет, как должна быть организована изолированная
	LDAP-инфраструктура хотя бы для одноуровневого класса с одним
	сервером. Факты успешного внедрения и сопровождения LDAP на
	местах не предлагать: у меня они тоже имеются, и я
	представляю, чего стоит такое внедрение.

Re: [Comm] Question on FTP

[Maxim Tyurin]

Fr. Br. George writes:

> Плюс, разумеется, ежедневное администрирование OpenLDAP (есть работающие
> и проверенные альтернативы?), в случае зависния/отказа которого (что
> бывает) виснут и все авторизационные механизмы всех клиентов, а иногда и
> база приходит в нерабочее состояние.

Альтернативы RedHat Directory server
Novell iDirectory (платный)

-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Question on FTP

[Michael Shigorin]

On Mon, Sep 18, 2006 at 04:17:02PM +0400, Fr. Br. George wrote:
> > Или кое-кто всё-таки почитает про LDAP.
> Не морочь людям мозги.

Экой.

> Для начала. LDAP никак не влияет на "пограничность" Samba и её
> протоколов.

Какую-такую пограничность?  Ты winbind приплёл зачем-то или как?
Смысл именно через самбу протаскивать всю auth, а не использовать
её как один из "оконечников" к стораджу аутентификационных
данных?

Ты вообще что решил доказать-то?  Я с тобой во многом согласен,
между прочим.  Но не в подобном эээ... оригинальном подходе --
героически придумать проблему и яростно бороться как с ней,
так и с объясняющими, почему именно так обычно не делают.

> LDAP -- это backend, и тогда читай-не читай, без разницы, где
> ты хранишь учётную информацию, хоть в файлах, хоть MySQL. Ни
> лучше, ни хуже не будет.  Либо же LDAP -- это _механизм_, то
> есть хрень, с которой надо пересобрать все приложения, что ты
> планируешь использовать в production (некоторые из них
> действительно поддерживают LDAP, каждая по собственной схеме). 

Ты же вроде знаешь про PAM?  Или считаешь, что у меня слакварь 
и прямо-таки надо всё пересобирать чуть что? :-E

> В любом случае добавится ещё проблема синхронизации одинаковых
> полей, которые в разных схемах названы по-разному, а также
> зависящих друг от друга полей, типа smb-пароля и pam-хеша. Эта
> проблема непростая, но решаемая, только мне неизветсны факты её
> решения не на коленке. Если есть ссылочка -- поделись.

smbldap-passwd

> Плюс, разумеется, ежедневное администрирование OpenLDAP (есть
> работающие и проверенные альтернативы?),

Есть RHDS, куски которого понемногу кидали в opensource,
но фактов эксплуатации пока не встречал.  Впрочем, openldap-2.3
для нашего с тобой ареала вполне прилично работает.  Да и 2.2
получалось приготовить.

> в случае зависния/отказа которого (что бывает) виснут и все
> авторизационные механизмы всех клиентов, а иногда и база
> приходит в нерабочее состояние.

Некоторые же и про ldap replication читали.  И делали.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Question on FTP

[Fr. Br. George]

On Mon, Sep 18, 2006 at 07:44:00PM +0300, Michael Shigorin wrote:
> > Для начала. LDAP никак не влияет на "пограничность" Samba и её
> > протоколов.
> Какую-такую пограничность?
PAMо-непригодность.
>  Ты winbind приплёл зачем-то или как?
Зачем-то.
> Смысл именно через самбу протаскивать всю auth, а не использовать
> её как один из "оконечников" к стораджу аутентификационных
> данных?
Не понял вопроса. Если вопрос был "А смысл?", то иногда этот смысл есть,
но чаще нету.

> Ты же вроде знаешь про PAM?  Или считаешь, что у меня слакварь 
> и прямо-таки надо всё пересобирать чуть что? :-E
Я знаю про PAM и не считаю, что у тебя слакварь. Но к чему ты это завёл
-- ума не приложу.

> > В любом случае добавится ещё проблема синхронизации одинаковых
> > полей, которые в разных схемах названы по-разному, а также
> > зависящих друг от друга полей, типа smb-пароля и pam-хеша. Эта
> > проблема непростая, но решаемая, только мне неизветсны факты её
> > решения не на коленке. Если есть ссылочка -- поделись.
> smbldap-passwd
Не издевайся, а? Эта поделка _не_ решает проблемы пересечения
пространства имён схем, равно как и проблемы зависимости полей. Это
всего лишь утилита для одновременной смены двух паролей. Смена проходит
неатомарно, так что ещё и гонки в ней есть, и тупики. Не рекомендую в
тяжёлой эксплуатации.

Что хотелось бы: механизм задания зависимости полей на серверной
стороне. Типа hook-ов: поменялось такое-то поле -- фигак, вызвался
обработчик, вычислил значения другого поля, записал. Тогда в поделках не
будет необзодимости. Например, для обновления всех паролей достаточно
будет smbpasswd (новая самба умеет сама ходить к LDAP). вот эту-то
ссылочку мне и хочется.

> Есть RHDS, куски которого понемногу кидали в opensource,
Как всё самодельное в RH, RHDS -- это ужасный кодомусор, кувалдами
превращённый в сверкающий куб, который разлагается на кодомусор при
первой же попытке переноса/модификации.

> но фактов эксплуатации пока не встречал.
В RH -- эксплуатируют. Даже доклад на Протве про это был.

>  Впрочем, openldap-2.3
> для нашего с тобой ареала вполне прилично работает.  Да и 2.2
> получалось приготовить.
Получалось приготовить -- самое правильное словосочетание. До
дистрибутивного состояния это самое "получалось приготовить" дока никто
не подвигнулся довести.
 
> Некоторые же и про ldap replication читали.  И делали.
На OpenLDAP? Насколько я помню -- ручная работа, никакой автоматики.

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Michael Shigorin]

On Wed, Sep 20, 2006 at 03:31:49PM +0400, Fr. Br. George wrote:
> > > Для начала. LDAP никак не влияет на "пограничность" Samba и
> > > её протоколов.
> > Какую-такую пограничность?
> PAMо-непригодность.

Так бы сразу и сказал.

> >  Ты winbind приплёл зачем-то или как?
> Зачем-то.

А.

> > Смысл именно через самбу протаскивать всю auth, а не
> > использовать её как один из "оконечников" к стораджу
> > аутентификационных данных?
> Не понял вопроса. Если вопрос был "А смысл?", то иногда этот
> смысл есть, но чаще нету.

Вопрос был "смысл предлагать такой вариант и с ним сражаться" :)

> > Ты же вроде знаешь про PAM?  Или считаешь, что у меня
> > слакварь и прямо-таки надо всё пересобирать чуть что? :-E
> Я знаю про PAM и не считаю, что у тебя слакварь. Но к чему ты
> это завёл -- ума не приложу.

Ладно, проехали...

> > > В любом случае добавится ещё проблема синхронизации
> > > одинаковых полей, которые в разных схемах названы
> > > по-разному, а также зависящих друг от друга полей, типа
> > > smb-пароля и pam-хеша. Эта проблема непростая, но решаемая,
> > > только мне неизветсны факты её решения не на коленке. Если
> > > есть ссылочка -- поделись.
> > smbldap-passwd
> Не издевайся, а? Эта поделка _не_ решает проблемы пересечения
> пространства имён схем, равно как и проблемы зависимости полей.
> Это всего лишь утилита для одновременной смены двух паролей.
> Смена проходит неатомарно, так что ещё и гонки в ней есть, и
> тупики. Не рекомендую в тяжёлой эксплуатации.

Оно работало в достаточно тяжёлой.  В тупики не припомню
упираний, а гонки по смене пароля -- эт к каким-нить психам,
которые passwd оптимизируют под свой K6.

> Что хотелось бы: механизм задания зависимости полей на
> серверной стороне. Типа hook-ов: поменялось такое-то поле --
> фигак, вызвался обработчик, вычислил значения другого поля,
> записал. Тогда в поделках не будет необзодимости. Например, для
> обновления всех паролей достаточно будет smbpasswd (новая самба
> умеет сама ходить к LDAP). вот эту-то ссылочку мне и хочется.

Сюда не рыл.  (у нас хватает грамотных в LDAP людей, чтобы ещё
мне лазить)

> > Есть RHDS, куски которого понемногу кидали в opensource,
> Как всё самодельное в RH, RHDS -- это ужасный кодомусор,
> кувалдами превращённый в сверкающий куб, который разлагается на
> кодомусор при первой же попытке переноса/модификации.

Ты уже смотрел?

> > Впрочем, openldap-2.3 для нашего с тобой ареала вполне
> > прилично работает.  Да и 2.2 получалось приготовить.
> Получалось приготовить -- самое правильное словосочетание. До
> дистрибутивного состояния это самое "получалось приготовить"
> дока никто не подвигнулся довести.

Ну привести-то можно [было] -- статической сборкой с
рекомендуемой libdb4, лучше ещё и с наложением на оную
некоторых рекомендуемых там же патчей.

С 2.3/4.4 это вроде (пока?) пройденный этап, работает.

> > Некоторые же и про ldap replication читали.  И делали.
> На OpenLDAP? Насколько я помню -- ручная работа, никакой
> автоматики.

Подъём репликации?  Да.  Репликация?  Само.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Question on FTP

[Fr. Br. George]

On Wed, Sep 20, 2006 at 08:53:17PM +0300, Michael Shigorin wrote:
> Вопрос был "смысл предлагать такой вариант и с ним сражаться" :)
В случае обслуживания виндовз-сетей такой смысл есть.

> > > smbldap-passwd
> > Смена проходит неатомарно, так что ещё и гонки в ней есть, и
> > тупики. Не рекомендую в тяжёлой эксплуатации.
> Оно работало в достаточно тяжёлой.  В тупики не припомню
> упираний,
Падение/зависание/перегрызание провода/whatever после обновления одного
пароля и до обновления другого.
> а гонки по смене пароля -- эт к каким-нить психам,
> которые passwd оптимизируют под свой K6.
Нет, всего лишь для двух человек, одновременно запустивших эту утилиту
на одну и ту же учётную запись.

> > Что хотелось бы: механизм задания зависимости полей на
> > серверной стороне.
> Сюда не рыл.  (у нас хватает грамотных в LDAP людей, чтобы ещё
> мне лазить)
Правильно, зачем писать программу, если есть кому сделать вручную?

> > Как всё самодельное в RH, RHDS -- это ужасный кодомусор,
> Ты уже смотрел?
Я смотрел на лицо человека, который смотрел в код :)

-- 
			Георгий Курячий (aka Fr. Br. George)
			Руководитель образовательных проектов ALT Linux
			mailto : george at altlinux_ru

Re: [Comm] Question on FTP

[Michael Shigorin]

On Fri, Sep 22, 2006 at 04:50:12PM +0400, Fr. Br. George wrote:
> > > > smbldap-passwd
> > > Смена проходит неатомарно, так что ещё и гонки в ней есть, и
> > > тупики. Не рекомендую в тяжёлой эксплуатации.
> > Оно работало в достаточно тяжёлой.  В тупики не припомню
> > упираний,
> Падение/зависание/перегрызание провода/whatever после
> обновления одного пароля и до обновления другого.

"Не пущает" => ещё раз пнули ту же педаль.

Кирпич на голову, между прочим, тоже может упасть прямо между
двух ответов тебе -- так что теперь, оставить тебя в покое? ;-)

> > а гонки по смене пароля -- эт к каким-нить психам,
> > которые passwd оптимизируют под свой K6.
> Нет, всего лишь для двух человек, одновременно запустивших эту
> утилиту на одну и ту же учётную запись.

Ну с сетями по десь тыщь контуперов сталкиваться не приходилось,
двести-пятьсот -- это люди в одной комнате, которые не сильно
любят из неё вылазить обычно.  А на 10K всё равно придётся
что-нить вроде eDirectory брать и соответственно учить тамошние
грабли и пинать тамоший суппорт.

> > > Что хотелось бы: механизм задания зависимости полей на
> > > серверной стороне.
> > Сюда не рыл.  (у нас хватает грамотных в LDAP людей, чтобы
> > ещё мне лазить)
> Правильно, зачем писать программу, если есть кому сделать
> вручную?

Ты можешь попробовать набросать
http://www.freesource.info/wiki/TZ?
Всё толку больше.

> > > Как всё самодельное в RH, RHDS -- это ужасный кодомусор,
> > Ты уже смотрел?
> Я смотрел на лицо человека, который смотрел в код :)

А, ну я его не знаю.  А смотреть на лица людей, которые смотрят
e.g. в mozilla, уже давно привык.  Равно как и в себе
перфекциониста придавил.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/