Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Posts (3 страница со старыми записями)

GNOME Recipes

Matthias Clasen продолжает знакомить нас с его проектом, приложением GNOME Recipes. Как понятно из названия, оно предназначено для управлениями рекептами приготовления еды. Несмотря на то, что не все опенсорс-разработчики удовлетворяются шаурмой, пиццей и колой/пивом, такого приложения в составе GNOME не было.

Конечно, непонятно, почему нельзя использовать MySQL-базу и работать с рецептами в удобном консольном режиме с помощью мощного интерфейса SQL-команд, но выглядит неплохо.

https://blogs.gnome.org/mclasen/files/2017/03/appdata-news.png

Новые условия использования GitHub

Недавно изменились условия использования GitHub. Некоторые разработчики, когда вчитались, то решили, что условия явно противоречат требованиям ряда открытых лицензий, а кое-кто даже решил полностью удалить свои репозитории с GitHub.

Все это напрямую затрагивает и нас, но, к сожалению, публично комментировать юридические вопросы по существу никто не будет. Тем не менее, участник Fedora Legal, юрист SFLC и патентный адвокат Red Hat, Richard Fontana, обозначил свою точку зрения по поводу такого радикального прочтения новых условия использования GitHub - это неправильная трактовка. Richard хорошо знаком с юристами GitHub, а они с ним, и благодаря такой дружбе, в GitHub следуют его советам (например, как указывает сам Fontana, в новом ToS GitHub явно используется предложенная Ричардом концепция "inbound=outbound").

Печально, что у юристов GitHub в этот раз не удалось поговорить с разработчиками так, чтобы мы, разработчики, поняли суть изменений правильно. Надеемся, что наши коллеги сумеют предложить им более четкие и понятные формулировки по ряду болезненных вопросов. К сожалению, и наша в этом вина - гитхабовцы приглашали к обсуждению новых ToS за две недели до публикации финальной версии, но, судя по всему, те, кто распространяет собственные интерпретации новых ToS, проигнорировали предложение. Плоховато в коммьюнити с горизонтальными связями, ничего не поделать.

Да, и удалять исходники мы с GitHub, разумеется, не будем.

Тестирование GCC

Не так давно вышел SystemTap 3.1, и в честь этого события хотелось бы поговорить о тестировании.

Наш коллега, инженер Red Hat, David Malcolm, опубликовал заметку о том, как тестируется GCC, и какие можно ожидать улучшения. Напомним, именно он работал над включением unit-тестов в кодовую базу GCC.

Тестирование собранного ПО, это хорошо, но еще лучше, чтобы ошибки выявлялись на этапе компиляции. Еще один наш коллега, Martin Sebor, опубликовал заметку о том, какие можно использовать флаги GCC для поиска подозрительных мест в коде на ранних этапах сборки и привел примеры ошибок в коде, выявляемых при сборке с этими флагами.

http://s.pikabu.ru/post_img/2013/04/07/7/1365327582_998102211.gif

Разработчик не обращает внимания на предупреждения компилятора

systemd 233

Вышел systemd 233уже доступен в Fedora Rawhide).

В этот раз изменения (на русском, на OpenNET.ru)в основном сконцентрированы в systemd-networkd, поддержке контейнеров. Также systemd перешел на Python 3, а dbus-скрипты перенеслись из /etc в /usr. Вообще, изменений довольно много, и рассмотреть что-то огромное уже непросто.

Когда пытаешься прочесть ChangeLog к очередному релизу systemd

Объявили список организаций-участников GSoC 2017

Студенты и аспиранты, внимание! Только что официально объявили список организаций-участников Google Summer of Code 2017. Если вы еще не решили, чем заняться летом, то это вполне достойное, интересное, и финансово полезное занятие.

Выбирайте интересный вам OpenSource-проект, в нем ищите интересную задачу (или предлагайте свою), и подавайте заявку.

Разработка SELinux-модуля для пользователя

На Хабрахабре продолжили публикацию статей, посвященную настройке SELinux:

Разработка SELinux-модуля для пользователя tutorial

Это вторая статья из цикла

image1

Сегодня мы поговорим о SELinux-пользователях, их создании, привязке, правам и другим вещам. Зачем это делать? Есть много причин. Для меня главной причиной было выдать доступ для техподдержки для рутинных операций (таких как ребут, чистка логов, диагностика итд), но без доступа к критичным данным и изменению системных функций.

Предположения

В тексте будет содержаться много технической информации, поэтому автор предполагает, что читатель:

  • Прочитал прошлую статью
  • Имеет под рукой CentOS 7
  • На котором установлены пакеты setools-console, policycoreutils-devel, selinux-policy-devel, policycoreutils-newrole
  • И включен SELinux в режиме enforcing с политикой targeted или minimum

Это все про вас? Тогда поехали!

Пользователи и роли

Основное назначение пользователей — хранить список ролей, которые он может использовать. Пользователи по-умолчанию уже представлены в политике targeted или minimum, можете посмотреть командой semanage user -l.

image2

Как известно из прошлой статьи, именно роли являются контейнерами для типов, а именно на типы вешаются все необходимые правила. Таким образом, пользователь просто расширяет это дерево, создавая больше возможных вариантов. Обратите внимание: если у пользователя есть та или иная роль, он может самостоятельно переключиться в нее, используя команду newrole. Таким образом, разрешив пользователю роль sysadm_r или unconfined_r, вы автоматически даете ему неограниченные права на систему.

Пользователи и пользователи

Между Unix-пользователем (тем, который имеет UID) и SELinux-пользователем (тем, который имеет контекст) есть тонкая связь, которой можно управлять при помощи команды semanage login. Связь это односторонняя: id -Z user1 вам ничего не покажет. Специальный пользователь __default__ обозначает всех пользователей, не перечисленных в системе.

image3

Создание пользователя (простой способ)

Самый простой способ создать пользователя из готовых ролей — использовать semanage user -a. Предположим, нам нужен просто новый пользователь с дополнительным набором ролей:

image4

Таким образом мы получили пользователя, который имеет возможность админить web. Теперь мы можем задать для него пользователя:

image5

Контекст

Об этом мало где пишут, но мало просто создать пользователя. Если его контекст отличается от default_context, для него необходимо настроить файл контекстов. Подробнее см. man user_contexts. Настроим файл и для webadm_u:

image6

Проверка

Зайдем под пользователем webadm:

image7

Сменим uid на 0 и попробуем что-нибудь «сломать»:

image8

Сменим роль на webadm_r и попробуем теперь:

image9

Что и требовалось доказать — мы сделали админа, который может админить только веб. К сожалению, количество ролей «по-умолчанию» сильно ограничено. Список можно посмотреть тут.

Создание пользователя (правильный способ)

Давайте сделаем все тоже самое, но например для администрирования docker, причем напишем его с нуля. Модуль будет очень простой. Что нам нужно разрешить?

  1. Вход по ssh
  2. Доступ к sudo (UNIX-права никто не отменял)*
  3. Администрирование файлов, папок и сервиса докера
  4. Исполнение бинарников докера (docker, runcon)
  5. Коннект к сокету докера

Прим.: группа docker на последней версии CentOS7 не имеет доступа к /run/docker.sock по-умолчанию.

Напишем модуль и контекст-файл:

# новый модуль
policy_module(dockeradm, 1.0.3)
# объявляем новую роль
role dockeradm_r;
# стандартный шаблон для НЕ-админа
userdom_unpriv_user_template(dockeradm)
# разрешаем dac_override
allow dockeradm_t self:capability { dac_override dac_read_search };
# разрешаем sudo
sudo_role_template(dockeradm, dockeradm_r, dockeradm_t)
# разрешаем управлять файлами и папками контейнеров
container_admin(dockeradm_t)
# разрешаем исполнять исполняемые файлы контейнера
container_runtime_exec(dockeradm_t)
# разрешаем коннект к сокетам контейнера
container_stream_connect(dockeradm_t)
# макрос gen_user создает пользователя так-же, как semanage user -a
# он всегда должен быть в самом конце файла
gen_user(dockeradm_u, dockeradm, dockeradm_r, s0, s0)

Скомпилируем и установим модуль:

image10

Настроим пользователя и контекст:

image11

Проверим, что нас пускает в систему:

image12

Проверим наши права:

image13

Как говорит Apache, It works!

Подведение итогов

Создание SELinux-пользователей — важный шаг к созданию полноценного рабочего окружения, в котором каждый сотрудник занимается своим делом и при этом не мешает другим. Будь то хостинг-провайдер, студия разработки или банк, всегда есть ситуации, когда разделение доступа необходимо. Включайте SELinux и наслаждайтесь :)

Docker в production

Коллега, анонимный аналитик, анонимно пишущий анонимные посты в анонимном блоге (т.е. как ни крути, авторитетный и беспристрастный источник) продолжил морщить веревкой море любителей Docker.

За прошлый заход он прославился на всех иностранных онлайн-ресурсах про Open Source. К сожалению, нужно признать, что некоторые моменты резанули глаз.

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

Инженеры в целом положительно оценивают перспективы Docker

Предложен новый API для BSD-sockets

Устаревание POSIX, это не фантазия наших коллег, а суровая реальность. Стандарт устарел и для хранения данных, и для передачи данных по сети. Если по хранению данных у нас есть варианты, то на сетевую подстистему пока никто не покушался. До недавних пор.

Martin Sustrik, инженер Google и коллега Pieter Hintjens по разработке ZeroMQ, предложил переработать BSD sockets API. Он создал репозиторий на GitHub, в котором выложил первый вариант предложенных изменений и ряд примеров.

Подозреваем, что любителей юниксвэя ждут тяжелые времена в этом году.

Планы по улучшению поддержки Bluetooth в Fedora

Наш коллега, Nathaniel McCallum, уставший от нестабильной работы Bluetooth в Fedora, занялся созданием тестовых сценариев для Bluetooth-устройств.

Проблема в том, что поддержка Bluetooth разбивается на ядро (где никто ничего не тестирует, напомним) и userspace, а пользователь просто видит, что устройство не работает, и пишет точно так же в багзиллу - "устройство XXX не работает".

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

Вот как раз эту проблему и хочет решить Nathaniel. Пока готовы краткие инструкции по тому, как протестировать работоспособность Bluetooth-устройства при обновлении. Осталось только придумать, как предложить пользователям проверить поддержку вовремя.

CoreOS прекращает разработку Torus

Вслед за прекращением разработки fleet, CoreOS официально отказывается от дальнейшей разработки Torus.

Torus, это был проект распределенного хранилища (DDS), о котором мы вам рассказывали. С первых же дней, было не очень понятно, какова его ниша, и почему надо выбирать его, а не конкурирующие проекты, поэтому довольно ожидаемое решение разработчиков CoreOS о его закрытии нас сильно не удивило.