Резюме про права доступа
Группы бывают на всё сразу, тяжело обеспечить мелкие разрешения. Для этого существуют разные вещи, когда категоризируются не только пользователи.
Как нарушать права доступа, если надо. Процессы, запущенные от uid 0 могут всё. ДЗ. Назвать права доступа, которые рут не может нарушать. setuid, setgid Выдача прав на capabilities -- нововведение. Долгим колупанем можнонайти дыру в истсеме или в ядре, но простые правила соблюдения безопасности могут гар антировать что обычныйпроцесс лишних прав не получит. Классический способ атаки на юних систему -- попытка заставить какую нибудь программу запущенную от имени суперпользователя выполнить какой-нибудь свой код. Даже в этом случае объекты атак очень сильно ограничены. Программы, которые работают от рута и которые доступны снаружи -- их счетное конечное число, и это число не очень большое. Вычитать их код -- задача не очень сложная. Все остальные программы, если только рут их сам от себя не запустит не имеют возможности достучаться до серьезных прав в системе. Обычному пользователю с правами рута надо делать три больших задачи. Первая -- установка по, такого, из пакетов. Вторая -- настройка аппаратуры капризной в случчае если она не работает из коробки. третье -- управлени сетью в случае если "само работает" работать не хочет. Все кроме первого постепенно из повседневной пркатики вытесняются. Попробовать как-то заполучить и повысить свои права достаточно тяжело, потому что инструментов, поводов и возможностей для этого мало.
С этой точки можно начать разговор в разные стороны. Что такое чрут, поговорить, например. Но есть тема -- установка программного обеспечения, ок оторой надо поговорить.
Установка ПО
Тема широкая. Это, как было уже отмечено достаточно спецефичная, с одной стороны для линукс поле деятельности. С другой стороны оно вполне инваринтно -- для любого дистрибутива будут некоторые одиаковые специфики.
Практически любые программы, которые вы ставите под линукс вы ставите не волшебными установщиками, а запускаете одну единственную программу установщик, которая ставит пакеты, коих тысячи. Рассмотрим разные подходы.
Первый подход "ПО -- само собой дистрибутив"-- Виндоус-вэй. ОПлатформа для запуска приложений. Ваше приложение должно распространяться в такой форме, чтобы на любой из этих патформ оно заработало. Как создатель такого по вы предполагаете что на той платформе может не быть необходимыз компонент. С целью достичь цели "все начнет работать после установки" вы в дистрибутив закладываете разделяемые библиотеки, картинки, бинарники, данные -- всё. Результатом установки -- все разворачивается в некое место в фс и там, видеале, работает. Но это в идеале. На практике после развертывания файлов надо иногда помодифицировать ос, поэтому установщики становятся хитрее, к установщику надо поставлять разустановщик. В какое то время в микрософте изобрели микрософт инсталлер, но им пользуются не все.
Почему возникает концепция по==дистриьутив. Мы имеем очень огр представление о программном наполнении таргет платформы. Даже если представление мы имеем, со стороны программной системы мы не имеем адекватной остнастки чтобы это программное наполнение там возникло, поэтому мы таскаем все с собой. В случае линукса принципиальных проблем нет. Разработка дистрибутивов ведется внутри сообщества и для удобства сообщества это делает централизованно. Есть некая сборочница и она в постоянном режиме из обнавляемых исходников собирает бинарники. В сборочницу вкладываются исходники, а вылезают -- пакеты. Понятное дело, что множество этих пакетов, которые сообщество подготовило для работы в составе дистр может быть сколь угодно большим -- зависит от размеров сообщества. В состав исходников входит не толкь то, что из апстрима, но и то, что пишут майнтейнеры ( спеки). Свободное лицензирование позволяет делать вот этот вот механизм центализованно вообще для всего по с которым в принципе работает сообщество. Вместо системы, когда у нас разные программные продукты лежат на сайте производителя и он не проверял, работает ли оно под вашим линуксом, мы имеем систему, когда сообщество вокруг дистрибутива скармливает исходники сборочнице и образуется большое хранилище, в котором есть пакеты. Предполагается, что пакеты в хранилище уж как миниумм не нуждаются в замыкании "по==дистрибутив". Сборочница и есть такое замыкание. Мы не тащим все с собой, а прописываем зависимости от других пакетов.
В силу единого информационного и технологического пространства мы можем рассчитывать на то, что если программа собралась, то то что нужно для ее работы в хранилище есть. Хотя строго говря это неверно и это надо проверять специальныой дисциалиной. Но такие вещи как, например, разделяемый библиотеки проверяются автоматом.
Мы превращаем работу с пакетом в адский ад. Раньше был один пакет, теперь вместо одного зачастую надо ставить много. Кстати андроид и макос пакетируются изолированно -- там есть некая общая часть ( в адндроиде их виртуалка) всё остальное приезжает изолированно. В случае изолированного пакетирования мы получаем набор по, которые таскает за собой одинаковые библиотеки (например кутэ или гтк). И ладно если там одинаковые версии билиотек и умные разработчики. а если разработчик не очень, то разные версии могут экспортировать одинаковые символы не отличаясь сонеймами.
Первое свойство пакета -- пакет в линукс это просто архив. Сейчас гворится про binary-based. Пакет это просто архиив, который ваш установщик пакетов разархивиарует в корень. Но этого недостаточно. Как удалить пакет? Надо удалить все файлы которые в нем были. Поэтому при установке пакет должен хзарегестрироваться и сказать, из каких файлов он сотоит. Пакет это такой архив, который при установке регестрирует информацию, а при удалении может ее удалить. Какая еще информация может регистрироваться при установке кроме списка файлов? Файлы бывают трех родов. Представим, что вы установили сетуидный продукт, и у него внезапно изменился хэш бинарника. Стоит очень сильно задуматься. Есть специальные программы,которые проверяют, не поменялись ли внезапно хэши, права, итд. С другой сторны, есть файлы, которые меняться точно будут -- конфиги.
Все, что входит в состав хранилища, собирается по общему сценарию. регистрацией занимается диспетчер пакетов. Это он ходит в базу, добавлеят и убавляет информацию. Но еще иногда при установке нужно производить дополнительные действия. Допустим приложение должно появится в меню. Для этого оно должно разложить в специальные папочки десктоп файлы. Появление такого десктоп файла должно привести к перегенерации меню для всех установленных графических сред. Ну или например устанавливаете какой-то плагин для апаша. Неплохо было бы апаш перезапустить. Или вы удаляете пакет с апашом, неплохо было бы завершить процесс, которые работает. Вобщем, иногда надо совершать при установке и удалении некоторые дополнительные действия. Такие системные сценарии, которые традиционно зовутся постустановычными, они не очень большие. Как правило это одна-две команды, вызов какого-нибудь скрипта. Как правило они совсем небольшие. В спецификации пакета в альте они указываются прямо внутри спецификации.Отличие системных сценариев состоит в том, что но специфично для каждого пакета.
В рпм есть 4 вида сценариев
- до установки
- после установки
- до удаления
- после удаления
В дебиане мест больше, птому что там есть специальная стадия "настройка", которая дает еще два места ( при установке, при удалении) и есть ещё-какой то седьмое место.
Из привденных примеров как минимум первый вызывает легкое недоумение. Зачем мне, как майнтейнеру пакеты каждый раз, когда я таскаю десктоп файл, вручную запускать перегенрацию меню. Главное, перегенерацию меню надо запускать всегда, когда в определенной папке появляется новый файл. Эти сценарии вообще можно не писать в пакет, это триггеры. Они запускаются всякий раз, когда устанавливаются пакеты с определенными свойствами. Если вы ставит ман, то неплохо было бы запустить переиндексацию, итд, итп.
Функция триггера облегчает жизнь майнтейнеру. Но это еще и улучшение качества в целом, потому что майтейнер может полениться, забыть, ещё что-нибудь. Ну и на уровне всей системы если мы хотим поменять тригеррищаяся действия, мы можем это легко централизованно делать.
Это что касается свойства паета как файла. У пакета есть как минимум еще два свойства. Первое свойство -- зависимости. Что такое зависимости -- это ситуация, когда для установки одного пакета необходимо, чтобы в системе существовали еще пакеты. Неудовлетворенные зависимости это как подавленные влечения. Поговорим про то, какие зависимости бывают. Зависимоть пакета на пакет. Вы, как майнтейнер говорите -- "для работы моего пакета нужен вот тот пакет". Диспетчер сможет такие пакеты докачать и поставить. Более частая зависимотсть -- не на пакет, а на "виртуальный пакет", функциональность. Есть почтовый вебдвижок. Вообще говоря, чтобы она работала, нужен вебсервер. Какой именно -- не суть важно. С этой целью майнтейнеры в хранилище договариваются, что некоторые пакеты предоставляют функциональность httpd. И в зависимостях пропишется именно это слово. У апта очень сложный мозг, какой из предоставляющих функцоиональность пакетов главнее? но этот мозг раотает не всегда.
Казалось бы, нас спасают зависимости на файл. Что для работы нам нужно libz.so.1.03 . Это файл, он лежит /usr/lib .У этого рода завсисмости один недостаток -- она слишком строгая. Допустим, слегка обновилась версия, работать пакет мог бы, но зависимость не удовлетвориться. Вобщем, зависимость на файлы штука неудобная -- то слишком жесткая, то слишком мягкая.
Вообще говоря апстрим заботится о том, чтобы у библиотек с разынми аби были разные soname. Смена аби обычно отмечается сменой старшей цифры в имени. Можно на это не заморочится, а предоставить функциональность libz1
Такого рода зависимость на функциональность весьма часта в репозиториях. Опера выложила пакет для альтлинукса с файловыми зависимостями подо все библиотеки.
Альтовая специфика
Очень много апстримов не заботится об изменении сонейма. Могут менять всё, а сонейм не менять. Поэтому сделали вот что. Из библиотеки вытаскваются экспортируемые символы, а потом для каждого пакета -- какие функции из этой библиотеки он берёт. Это всё сжимается.
ABI -- Application Binary Interface API -- Application Programming Interace
У пакетов могут быть конфликты. Пакеты могут называться одинаково. Например, была игрушка, которая называлась chromium. Появился хромиум, в итоге в альте переименовали обоих.
Или есть mailx, которая из ком строки работает с почтой. У неё есть несколько реализаций -- под бзд лицензией и под гну лицензией. Под гну она покруче. Мало того, что эти пакеты работают похоже, так у них еще и бинариник одинаково называются.
В этом случае регистрируется конфликт. Один пакет не встанет, если установлен второй. Если предполагается. что в системе могут существовать оба пакета, то майнтенеры должны догоовриться, что ни одна программа на самом деле не называется mailx, а они называются по разному и регистрируется альтенатива. получается картина
/usr/bin/mailx является символьной ссылкой в какое-нибудь достаточно глубокой место, например /usr/bin/mailx -> /etc/alt/mailx|/usr/bin/mailx-> /usr/bin/legacy.mailx
Конфликты нередки. Они могут быть следвстием либо ненужности программ, либо когда альтернатива -- способ дать понять, что одновременно этим программам работать не стоит.
Какими инструментами работать с пакетами?
Программа, которая работает с опроеделенным видом пакетов называется установщиком. Установщик работает с файлами и с установленными пакетами. Он умеет их устанавливать и удалять. Внутри пакета. сообразно этой схеме расположена информация о зависмостях. Работая с файлами установщик сам удовлетворить завсимости не может. Установщик может выдать списко завсимостей, и всё. Работа с таким установщиком пакетов это ад адский. Никто так и не делает, рпм это всего лишь установщик. Другое дело диспетчер пакетов. Такая программа работает сразу с хранилищами. То есть, она не обязана уметь ставить пакеты, она отдает это рпму. Но она умеет получать полный списко пакетов из хранилища, их версии, зависимости и описания. Она может строить дерево зависимостей, понимать какие пакеты посвежее, скачивать их и отдавать на установку. Соответственно, диспетчер работает с хранилищами, и это важная вещь. помимо массовой установки и удаления у диспетчера появлется новая задачка -- обновление. Очевидно, что обновление это совем не удаление и установка новой версии. Например, надо сохранять конфиги. При обновлении надо новые запасать, а старые оставлять. А если майнтейнер правильный, то он еще и скрипт пишет, который позволяет мигрировать конфиги со старой версии к новой. В случае рпм based старый стается, новый кладется рядом с добавкой new.
Почему в альте такая странная парочка -- рпм + альт? Исторически сложилось, что комманда хорошо разбиралась в рпм дистрибутивах. Но диспетчеры были ужасны. Маленькая дополнительная неприятность rpm -- redhat packet manager, и все путаются в том, что такое этот менеджер, не диспетчер ли он.
Домашнее задание впрок -- подключаете в диспетчер тучу хранилищ. Перечислить пробелмы, возникающие при использовании рассинхронизованных(безответственных) хранилищ.