?

Log in

No account? Create an account
Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Entries by category: it

HBAC в SSSD/FreeIPA (часть 2)
Speaker Rabbit
abbra
Написал модуль для тестирования HBAC:
https://www.redhat.com/archives/freeipa-devel/2011-July/msg00375.html

1. Симулируем доступ к службе, используя все включенные правила в IPA:
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh
--------------------
Access granted: True
--------------------

2. Симулируем доступ к службе, используя все включенные правила + указанные в --rules (возможно отключенные):
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule
--------------------
Access granted: True
--------------------

3. Симулируем доступ, используя только правила, указанные в --rules (--validate ограничивает список правил только теми, что в --rules):
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,new-rule --validate
--------------------
Access granted: True
--------------------
  Passed rules: new-rule
  Denied rules: my-second-rule

4. Симулируем доступ и получаем подробный отчет, какие из включенных в IPA правил сработали:
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh  --validate
--------------------
Access granted: True
--------------------
  Passed rules: allow_all
  Denied rules: my-second-rule, my-third-rule, myrule

--validate включает детальный показ результатов применения правил, а если используется вместе с --rules, то ограничивает список проверяемых правил только указанными в --rules.

По всей видимости, --validate нужно переименовать во что-то иное (--detail?) и перекрыть --all для указания того, что к --rules надо добавить все включенные правила в IPA, иначе логика не очень ясна, по крайней мере, коллега уже успел ошибиться при тестировании.

HBAC в SSSD/FreeIPA
Speaker Rabbit
abbra
Немного о том, чем я сейчас занят. Записи с тегом "заметки-на-полях" -- моя внутренняя кухня, не предназначенная для активного обсуждения и цитирования вне этого ЖЖ. Мой мозг пока с трудом привыкает к большому объему нового (и вспоминанию старого) кода, поэтому заметки скорее для себя, чем разъяснения для других. Если объем превысит выделяемое самим собой время, я просто отключу комментарии, чтобы не отвлекаться, не обессудьте.

Read more...Collapse )

Видео (1)
Speaker Rabbit
abbra
Построение экранного изображения, в принципе, довольно примитивное занятие. Если отбросить все безумные подробности, X11 и OpenGL, то дело сводится к наличию некоторого количества фрагментов памяти (буферов), имеющих разную структуру (глубина цвета, цветовое пространство, упаковка пикселов) и к механизму смешивания этих буферов. В конце концов, в контроллер дисплея попадает один или несколько буферов, представляющих растр, которые по довольно простым правилам смешиваются между собой. Скажем, в N900, таких аппаратных буферов три. Называются они планами -- графический и два видео-плана -- и по сути дела ничего, кроме этих планов в N900 и не важно. То, что имеется еще "трехмерный ускоритель", ситуацию особенно не меняет -- в конце концов, трехмерный ускоритель выдает "на гора" растровый буфер, который используется для заполнения графического плана.

Конечно, масса деталей затрудняет попытки представить все очень простым и легким.Collapse )

Получилось довольно большое введение. Зачем оно надо -- в следующей заметке.
Tags:

Анализмус Два
Speaker Rabbit
abbra
С 2005 года Coverity и Department Homeland Security проводят работу по усовершенствованию свободного кода. DHS выделила около 300000 долларов США, а Coverity за эти деньги обеспечила для отобранных 250 свободных проектов бесплатный доступ к своему средству статического анализа исходного программного кода, Prevent.

Prevent, ранее известный как Stanford Checker, довольно хорошо отлавливает разные ошибки вроде переполнения буферов и обращения по неправильным указателям, средний показатель ошибок там, где их на самом деле нет, составляет около 14%, это довольно низкое значение. Samba Team имеет доступ к результатам прогона Prevent по разным веткам Samba, мы даже попали в "круг второй" -- проекты, хорошо реагирующие на найденные ошибки и получающие доступ к более продвинутым функциям Prevent (11 проектов). Coverity периодически (обычно раз-два в день) запускает Prevent и делает доступным протоколы запуска участникам проекта. Например, у нас сейчас показатель 0.018 ошибок на 1000 строк кода, то есть, приблизительно одна ошибка на 56 тысяч строк кода, если я не ошибся с расчетами.

Coverity подвела итоги проекта за последние два года в отчете "Scan Open Source" (PDF, документ этот требует бесплатной регистрации на сайте Coverity). Некоторые интересные факты из него:
  • за два года общее количество обнаруживаемых ошибок в проектах сократилось на 16%;
  • между размером проекта и количеством ошибок существует всего-лишь линейная зависимость, а не экспоненциальная, как считалось раньше;
  • усложнение функций не ведет к увеличению количества ошибок в них, несмотря на то, что так думают практически все программисты;
  • наибольшее число ошибок приходится на обращения по нулевому указателю (27.95%) и утечку памяти (25.73%), а наименьшее -- на переполнение динамически распределенных буферов (0.31%) и использование негативных смещений до тестирования (0.21%).


Интересно, что на текущий момент общая база проанализированного кода в Prevent составляет около двух миллиардов уникальных строк, из которых 250 миллионов уникальных строк кода доступно под свободными лицензиями. Coverity, правда, отказывается проводить какие-либо сравнения качества между проприетарным и свободным кодом, ссылаясь на "несравнимость" в тех условиях, которые у них есть. К тому же, аудитории программистов пересекаются, поскольку многие "днем" пишут проприетарный код, а "ночью" -- свободный. Так что судить производительность доктора Джекилла и мистера Хайда Coverity не решается.

To 3 or not to 3?
Speaker Rabbit
abbra
Samba Team перешла на использование GNU GPLv3 практически сразу после публикации окончательной версии лицензии. Принятое в июле 2007 решение состоит в том, что весь код, выпущенный после ветки 3.0 (на сегодня это ветки 3.2 и 4.0) будет доступен под GNU GPLv3 (и отдельные компоненты под GNU LGPLv3). На практике это означает, что все приложения, использующие libsmbclient из Samba 3.2 и старше, клиентскую библиотеку для работы со стеком протоколов CIFS, должны быть совместимы с GNU LGPLv3.

В июле 2007 также было принято решение, что все новшества будут добавляться только в 3.2 и 4.0. Ветка 3.0 (текущая версия 3.0.26a) остается под GNU GPLv2 (и libsmbclient под GNU LGPLv2), однако для этой ветки будут выпускаться только обновления в безопасности.

На самом деле, лицензия на код проекта Samba не строго GNU GPL, а "GNU GPL конкретной версии или более новая версия по выбору пользователя". Это позволяет делать код совместимым с тем, что будет опубликовано под новыми версиями GNU GPL. Однако здесь же возникает некоторая проблема: код, опубликованный строго под лицензией GNU GPLv2, без "или более новая версия по выбору пользователя", становится несовместим с кодом под GNU GPLv3. Такая несовместимость возникла, например, у библиотеки QT: QT доступна строго под GNU GPLv2,

В результате, получается, что код, лицензированный строго под GNU GPLv2, несовместим с кодом, выпущенным под GNU GPLv3 и GNU LGPLv3 (или более поздними версиями этих лицензий). Заметьте, не новая лицензия несовместима, а старая запрещает такое совместное использование.

В рассылках разработчиков дистрибутивов постепенно начинаются дискуссии о том, что использование Samba 3.2 (когда она выйдет) потребует дополнительной работы по выяснению и устранению подобных несовместимостей. Естественно, дискуссии поляризуют и разработчики распались на два лагеря: "GPLv3" и "GPLv3 не нужна". Надо сказать, что определенная логика в позиции последних наблюдается, правда, она далека от практики и проблем, которые создание GNU GPLv3 было призвано адресовать.

Если дискуссия в devel@ в ALT Linux Team пошла скорее в продуктивном русле -- мы попытались выяснить что и как может лицензионно "поломаться" в случае появления в Сизифе версии libsmbclient под GNU LGPLv3 -- то в Fedora-devel-list@ быстро все скатилось в традиционную анти-GPLv3 колею; дело дошло даже до заявлений, что необходимо сменить SONAME библиотеки, поскольку она будет несовместима с предыдущим интерфейсом (на самом деле, совместима, а смену лицензии при всем желании не решают путем сегрегации библиотечных интерфейсов). Однако одно здравое замечание (от Nicolas Mailhot, он не связан с Samba Team) там прозвучало и его я бы хотел процитировать:
The samba project will continue to do maintenance and security fixes
on the last GPLv2 release however it won't get all the improvements of
the next one. So IMHO it's totally unrealistic to expect to keep using
the GPLv2 samba branch even mid-term. Users will start begging for
GPLv3 samba features soon.

That means all the projects that depend on samba will have to move to
GPLv3 compatibility quickly. There is no status-quo escape - the samba
people know they can not be replaced (past forks didn't get any
traction, and no one really wants to dig in MS bugs in their place)
and they've been deeply involved in EU MS litigation (so they know
GPLv2 is not sufficient). The probability of Samba going back to GPLv2
is actually lower than the probability of the kernel going GPLv3.

Some people have blinded themselves thinking their dislike of the FSF
was shared by everyone and boycotting the GPLv3 process would ensure a
bad license no one would use. Groups that had to taste real-world
litigation like Samba, however, have always make clear they were not
happy with GPLv2 and would move their code to GPLv3 no matter what
others chose.


По-русски:
Проект Samba по-прежнему будет выпускать исправления безопасности для последней версии, выпущенной под GPLv2, однако эта версия не будет включать в себя все улучшения, которые попадут в последующие выпуски. Так что, по-моему, полностью нереалистично ожидать использование GPLv2-версии Samba даже в среднесрочной перспективе. Пользователи скоро начнут просить возможности GPLv3-версии Samba.

Это означает, что все проекты, зависящие от Samba, будут вынуждены достаточно быстро обеспечить совместимость с GPLv3. Избежать этого невозможно -- Samba Team знает, что заменить ее труд нечем (предыдущие попытки форков не получили сколько-нибудь серьезного использования и никто не хочет вместо них погрязнуть в ошибках Microsoft), а также они очень серьезно вовлечены в антимонопольный процесс против Microsoft в Европе (так что они знают, что GPLv2 недостаточно). Вероятность того, что Samba вернется к GPLv2 на самом деле меньше вероятности того, что ядро Linux перейдет под GPLv3.

Некоторые ослепляют себя мыслью о том, что их неприязнь к FSF разделяется всеми остальными и бойкотирование процесса разработки и применения GPLv3 приведет к тому, что плохую лицензию никто не будет использовать. В то же время, группы, которые вынуждены сталкиваться с реальными судебными процессами (вроде Samba), со всей очевидностью демонстрируют, что GPLv2 недостаточно и что они будут использовать GPLv3 вне зависимости от выбора остальных.


Вернемся к приложениям, которые используют тем или иным образом libsmbclient. В GNOME это все приложения, которые собраны с поддержкой GNOME VFS. В официальной поставке GNOME таких приложений под строгой GNU GPLv2 немного: Evolution и Bug-buddy. В Evolution, на самом деле, лицензионный бардак -- с пожеланиями Novell использовать проприетарные расширения там все запутано и простое использование строго GNU GPLv2 вынуждает политические дискусси с Novell -- в них сейчас завязли ребята из Open Change. В Bug-buddy тоже все весело: код строго под GNU GPLv2, по пожеланиям оригинального автора, Якоба Беркмана (работает в Novell). Текущий мейнтейнер, Фернандо Эррера, не против перехода на GNU GPLv2 "или любая более новая версия по выбору пользователя", однако от Якоба мы с ним пока никакого ответа не получили. Якоб не участвует в разработке GNOME уже несколько лет.

С Trolltech и QT пока что вопрос открыт -- говорят, они до сих пор изучают GNU GPLv3. Однако решение в той или иной мере принять придется всем и последние демарши Баллмера демонстрируют насущную необходимость по крайней мере отдельных положений, включенных в GNU GPLv3.

GPLv3
Speaker Rabbit
abbra
За суматохой дней забыл о главном -- я, наконец, закончил перевод анализа черновых версий GNU GPLv3 по отношению к российскому законодательству, обещанный lqp еще летом, и отправил его Эбену Моглену. Надеюсь, что результаты кропотливой работы Федора учтут при выпуске GPLv3 draft 3. По крайней мере, Эбен ответил так:
From: Eben Moglen <moglen@>
Subject: Re: Comments for GPLv3 and Russian law compliance

Thanks. We will take these comments into account, and we are grateful
for the time and effort spent on creating them.

Regards,
Eben


Для желающих, английская версия опубликована тут.