Fakeroot linux что это

Обновлено: 03.07.2024

Есть много причин, по которым хорошую перспективную технологию могут не принимать в официальную ветку Linux — Линус славится своими жесткими требованиями к новому коду. Но от этого факта менее интересными такие технологии не становятся. И иногда ради них стоит пересобрать ядро с наложением стороннего патча.

Какими бывают линуксы

linux-rt

Пожалуй, самый известный сторонний патч. Позволяет превратить обычный Linux в ОС реального времени. И хотя главное применение такой операционки – промышленные и встроенные системы, на обычном десктопе она тоже может быть интересна. Например, тем, кто часто занимается обработкой звука или видео или постоянно грузит систему какими-нибудь ресурсоемкими вычислениями. Встречаются также свидетельства о положительном эффекте от применения этого ядра на highload-серверах. Я же ничего, кроме слегка упавшей общей производительности системы, не заметил.

$ sudo apt-get install linux-rt

В других же дистрибутивах ядро с этим патчем можно легко собрать. Для этого надо наложить патч на ванильное ядро и при конфигурировании указать опцию Processor type and features –> Preemption Mode (Complete Preemption (Real-Time)). И еще рекомендуется отключить опцию Kernel hacking –> Check for stack overflows, так как она повышает латентность. Чтобы можно было собирать некоторую статистику по времени отклика, при конфигурировании нужно также включить: Kernel hacking –> Tracers –> Kernel Function Tracer, Interrupts-off Latency Tracer, Interrupts-off Latency Histogram, Preemption-off Latency Traver, Preemption-off Latency Histogram, Scheduling Latency Tracer, Scheduling Latency Histogram, Missed timer offsets histogram.
После сборки ядро должно содержать в имени PREEMPT и RT, например:

Чтобы потешить собственное самолюбие, можно включить сбор статистики:

Саму статистику смотрим тут:

$ grep -v " 0$" /sys/kernel/debug/tracing/latency_hist/wakeup/CPU0

Самое интересное там: значения минимального, среднего и максимального времени отклика.

Широко известный в узких кругах анестезиолог-линуксоид Кон Коливас с переменным успехом поддерживает собственную ветку (точнее, набор патчей) Linux. Главным нововведением в его патчсете является новый планировщик BFS (Brain Fuck Scheduler), являющийся альтернативой стандартному CFS и показывающий, по результатам тестов, улучшенную отзывчивость ядра на десктопе (другими словами, при использовании BFS жадные до графических ресурсов приложения получают ощутимый прирост производительности, а раздражающие паузы, возникающие, например, при переключении между ресурсоемкими программами, которые требуют доступ к диску, становятся менее заметными, либо исчезают совсем).

ReiserFS

Но поддержка ядром ФС – это еще не все. Чтобы можно было оперировать с разделами reiser4, надо поставить reiser4progs. Во многих дистрибутивах этот комплект утилит есть в репозитории:

$ sudo apt-get install reiser4progs

Соответственно, основные операции с ФС:

mkfs.reiser4 – создать раздел с reiser4;
fsck.reiser4 – проверить раздел с reiser4;
measurefs.reiser4 – посмотреть параметры раздела с reiser4.

Grsecurity

Патч, содержащий потрясающее количество механизмов для повышения защищенности Linux-системы. Опции компиляции grsecurity расположены в Security options –> Grsecurity. Есть три уровня безопасности на выбор: низкий, средний и высокий. Низкий уровень рекомендован, когда более высокие уровни не подходят из-за использования нестандартного набора ПО. Он содержит:

В среднем уровне защиты дополнительно добавятся технологии:

дополнительные ограничения для приложений, запускаемых в chroot: запрет монтирования и mknod (создание именованных каналов, специальных символьных и блочных файлов), запрет на двойной chroot, запрет на запись в sysctl и другое;
ограничение прав на чтение /proc для пользователей, не входящих в заранее заданную группу (по умолчанию wheel);
ограничение записи в /dev/kmem, /dev/mem и /dev/port;
рандомизация адресного пространства;
серьезное логирование подозрительных событий (неудавшихся вызовов fork(), попыток изменения системного времени, сигналов вроде SIGSEGV и подобных);

Высокий уровень еще больше затягивает узлы, так как дополнительно:

ограничивает права на чтение /proc – теперь пользователи смогут читать из /proc информацию только о своих процессах. Можно также указать GID специальной группы, которая сможет читать любую информацию из /proc.
накладывает ограничения на работу процессов в chroot-окружении: отключение возможности устанавливать suid-бит, отключение возможности посылать некоторые сигналы внешним процессам, ограничение на выполнение таких системных задач, как изменение системного времени или перезагрузка компа;
добавляет дополнительное логирование (в том числе всех mount/umount);
включает рандомизацию стека ядра;
добавляет ограничение на чтение информации о ядре через системные вызовы для обычных пользователей (для root эта возможность остается).

Необязательно в качестве Security Level выбирать один из имеющихся уровней. Есть вариант Custom, позволяющий отдельно выбрать все необходимые опции. Еще одна интересная опция Grsecurity –> Sysctl support позволит включать/отключать параметры безопасности через sysctl без необходимости пересобирать ядро. Так как эта директива отрицательно влияет на общую безопасность системы, ее рекомендуется использовать лишь в тестовых целях.

Помимо уровней безопасности, при конфигурации можно включить/отключить RBAC (Role Based Access Control) – управление доступом на основе ролей. Управление пользователями и их ролями осуществляется с помощью специальной утилиты gradm2, присутствующей в большинстве дистрибутивов:

$ sudo apt-get install gradm2

Zen-kernel

Zen-kernel – наверное, самая большая пачка заплаток ядра в одном месте. Позиционируется как быстрое ядро для десктопов. Получить zen-kernel можно тремя способами:

скачать архив с последним релизом (за номером 2.6.34-zen1);
забрать версию с уже наложенными патчами из git'а;
скачать патч для нужной версии и наложить самому.

У них есть два репозитория: zen-stable.git (с патчами, наложенными на стабильное ядро) и zen.git (синхронизация с git-хранилищем Линуса и наложение тестовых патчей).
Набор сторонних патчей меняется от релиза к релизу и на данный момент включает в себя:

патчи от Кона Коливаса (в том числе BFS);
Reiser4;
Linux-PHC – проект, позволяющий снижать напряжение CPU для уменьшения энергопотребления и температуры;
обновленные и добавленные дрова (для Lenovo ThinkPad SL, Gamecube/Wii, Macbook, WiFi-чипов и другого);
Tuxonice – патч, реализующий продвинутый hibernate («спящий режим» – при выключении содержимое ОЗУ скидывается на винт, при включении – восстанавливается);
поддержка FatELF – формата бинарников, содержащего в одном файле варианты для нескольких архитектур (аналог Universal Binary в Mac OS X);
DazukoFS – виртуальная ФС, предоставляющая on access доступ к файлам. Широко используется различными антивирусами.

Универсальная сборка

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

$ sudo apt-get install linux-source

Но мне zen-kernel нравится больше, чем стандартное generic-ядро ubuntu, поэтому его и буду мучить. Поставим все, что может пригодиться для сборки:

$ sudo apt-get install build-essential libncurses5-dev \
libgtk2.0-dev libglade2-dev libqt3-mt-dev git-core

Добавим своего юзера в группу src, чтобы можно было без проблем собирать в /usr/src:

$ sudo usermod -a -G src adept

Клонируем git-репозиторий (приготовься скачать около 500 метров):

Смотрим, какие ветки есть в репозитории:

Выбираем последнюю патченную версию:

$ git checkout v2.6.34-zen1

Сорцы не обязательно вытягивать из git. Если ты ограничен по трафику или скорости инета, то быстрее и дешевле будет скачать патч и официальное ядро. Заплатка накладывается следующим образом:

$ cd /usr/src/linux-2.6.34
$ zcat ../patch-2.6.35.bz2 | patch -p1

Утилита patch также имеет замечательную опцию '--dry-run', позволяющую протестировать, как наложится патч, прежде чем его накладывать.
Далее выбираем способ конфигурирования ядра:

make config – для тех, у кого уйма свободного времени. Система задаст несколько тысяч вопросов (по одному на каждую опцию конфигурации);
make allnoconfig/allyesconfig – генерируется конфиг, в котором на все вопросы отвечено no/yes;
make defconfig – конфиг с настройками по умолчанию;
make randconfig – самый веселый способ – использует великий рандом для ответа на вопросы;
make oldconfig – при использовании старого конфига. Задаст вопросы только про те пункты, которых не было в старом конфиге;
make menuconfig – псевдографический, использующий ncurses, интерфейс;
make nconfig – одно из нововведений ядра 2.6.35. Тоже псевдографический, использующий ncurses, интерфейс, но выглядит несколько более свежо, чем menuconfig;
make xconfig – графический интерфейс на базе QT;
make gconfig – графический интерфейс на базе GTK.

Мне больше привычен интерфейс menuconfig.
Какие-то конкретные советы по конфигурированию ядра давать сложно – все очень сильно зависит от имеющегося окружения и желаемых результатов. Но я всегда придерживаюсь нескольких простых правил:

Все, что мне точно понадобится (в том числе поддержка ФС, на которой у меня /) и будет нужно часто, я включаю в ядро. Все, что может пригодиться или будет нужно редко – компилирую модулем. Все, что точно не пригодится, соответственно, выкидываем.
Опции с пометкой EXPERIMENTAL лучше не включать без крайней на то необходимости. Также не рекомендуется включать Device Drivers –> Staging Drivers. Ядро может просто не собраться или работать не стабильно.
Чтобы не путаться в ядрах, добавляю суффикс версии ядра в General Setup –> Local Version.

Также неплохой отправной точкой может стать конфиг дистрибутивного ядра.
После того, как конфиг готов (и сохранен в файл .config), можно приступать к сборке:

С помощью опции «-j» можно указать количество потоков, что немного ускорит компиляцию на многоядерном процессоре. В зависимости от мощности компа и опций конфигурации, ядро может собираться по часу и даже больше. После компиляции начинается установка:

$ sudo make modules_install
$ sudo make install

На самом деле модули просто скопируются в /lib/modules/, а ядро с конфигом – в /boot.
Создаем initrd для нашего нового ядра:

$ sudo update-initramfs -k v2.6.34-zen1 -c

Обновляем конфигурацию grub, чтобы он нашел новое ядро:

Все, можно идти в ребут, скрестив пальцы и затаив дыхание, загрузиться с новым ядром.

Компиляция. Debian-way

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

В Debian/Ubuntu за сборку ядра отвечает make-kpkg. Для того, чтобы воспользоваться make-kpkg, установим один пакет:

$ sudo apt-get install kernel-package

Генерация конфига происходит точно так же, как и в способе выше, а сборка несколько иначе:

$ fakeroot make-kpkg --initrd --revision=mykernel \
kernel_image kernel_headers modules_image

Эта команда сначала соберет ядро, а потом создаст два пакета: linux-image-version-revision.deb (бинарник и модули ядра) и linux-headers-version-revision.deb (заголовочные файлы ядра), которые будут лежать в /usr/src.

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

$ sudo dpkg -i /usr/src/*.deb
$ sudo reboot

make complete

К сожалению, журнал не резиновый, и рассказать получилось далеко не про все заслуживающие внимания патчи. За бортом остались OpenVZ и Xen, Openwall, а также целый класс патчсетов – дистрибутивные (ведь очень небольшое количество дистрибутивов использует ванильное ядро).

Скажи «нет!» ребуту

И все обновления установлены! Правда, «uname -a» все еще показывает старую версию. Зато

расскажет всю правду об установленных апдейтах.
В дополнение система еще имеет веб-интерфейс, где можно посмотреть статус всех своих подключенных серверов, умеет присылать на email уведомления о выходе новых патчей. И такое rebootless счастье стоит, в принципе, не так уж и дорого – $3,95 в месяц за один физический сервер (если серверов больше 20, то $2,95). Есть триальный доступ на 30 дней. А поддержка десктопной убунты вообще бесплатна.

В общем, сказка, если б не одно «но» – все это работает только со стандартным ядром твоего дистра – никаких тебе патчей и обновлений версий ядра.

Турбо-компиляция

Далеко не всегда получается с первого раза собрать идеально работающее ядро – обязательно забудешь включить какой-нибудь модуль или наложить какой-нибудь патч. А новая сборка, особенно на маломощном компе, может быть раздражающе долгой. В таком случае на помощь придет ccache, умеющий кэшировать результаты компиляции. В результате повторная пересборка проходит значительно быстрее. Для использования ccache при сборке ядра набирай

Весь кэш будет храниться в каталоге

/.ccache, а статистику по его использованию можно посмотреть с помощью команды

Пока что я могу понять, что fakeroot используется для передачи прав на файл, который должен быть root, когда он распакован / tar-файл. Мой вопрос, почему ты не можешь просто сделать это с Чоуном?

Этот ответ здесь описывает, что реальные системные вызовы выполняются с использованием реального uid / gid пользователя , так что опять же помогает fakeroot?

Как fakeroot останавливает нежелательные повышения привилегий в Linux? Если fakeroot может заставить tar создать файл, который принадлежит root, почему бы не сделать что-то похожее с SUID?

Из того, что я собрал, fakeroot просто полезен, когда вы хотите изменить владельца любых файлов пакетов, которые вы создали для root. Но вы можете сделать это с помощью chown, так где мне не хватает понимания того, как предполагается использовать этот компонент?

Вам не нужен fakeroot для компиляции ядра. Система сборки ядра не такая уж безумная. Связанное обсуждение касается создания пакета ядра Debian , в котором фактическая сборка ядра - это только один шаг. @ WumpusQ.Wumbley Я исправлю это, и не могли бы вы сказать мне, почему это так? Потому что fakeroot - это вещь Debian, а Linux - это больше, чем Debian? @ WumpusQ.Wumbley он должен работать на любом дистрибутиве.

Пока что я могу понять, что fakeroot используется для передачи прав на файл, который должен быть root, когда он распакован / tar-файл. Мой вопрос, почему ты не можешь просто сделать это с Чоуном?

Потому что вы не можете просто сделать это chown , по крайней мере, не как пользователь без полномочий root. (И если вы работаете от имени пользователя root, вам это не нужно fakeroot .) В этом весь смысл fakeroot : позволить программам, которые ожидаются от имени пользователя root, запускаться от имени обычного пользователя, в то же время делая вид, что операции, требующие root, успешны.

Обычно это используется при сборке пакета, так что процесс установки устанавливаемого пакета может продолжаться без ошибок (даже если он выполняется chown root:root , и install -o root т. Д.). fakeroot запоминает поддельное владение, которое он притворял, чтобы передать файлы, поэтому последующие операции, проверяющие владение, видят это вместо реального; это позволяет при последующих tar запусках, например, сохранять файлы как принадлежащие пользователю root.

Как fakeroot останавливает нежелательные повышения привилегий в Linux? Если fakeroot может заставить tar создать файл, который принадлежит root, почему бы не сделать что-то похожее с SUID?

fakeroot ничего не обманывает tar , он сохраняет изменения, которые хочет внести сборка, не позволяя этим изменениям влиять на систему, в которой находится сборка. Вам не нужно fakeroot создавать тарбол, содержащий файл, принадлежащий root и suid; если у вас есть бинарный файл evilbinary , работающий tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary от имени обычного пользователя создаст тарбол, содержащий evilbinary root и suid. Однако вы не сможете извлечь этот tarball и сохранить эти разрешения, если вы не сделаете это от имени root: здесь повышение привилегий не происходит. fakeroot это привилегия де- инструмент эскалации: он позволяет запускать сборку как обычный пользователь, сохраняя при этом эффекты, которые сборка имела бы, если бы она была запущена от имени пользователя root, что позволяет воспроизводить эти эффекты позже. Применение эффектов «по-настоящему» всегда требует корневых привилегий; fakeroot не предоставляет какой-либо способ их приобретения.

Чтобы понять использование fakeroot более подробно, рассмотрим, что типичная сборка дистрибутива включает в себя следующие операции (среди многих других):

установить файлы, принадлежащие пользователю root
.
заархивируйте эти файлы, все еще принадлежащие пользователю root, чтобы при извлечении они принадлежали пользователю root

Первая часть явно терпит неудачу, если вы не root. Однако при работе под fakeroot обычным пользователем процесс становится

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

Таким образом, вы можете запустить сборку пакета, не будучи root, и получить те же результаты, которые вы получите, если бы вы действительно работали как root. Использовать fakeroot безопаснее: система по-прежнему не может делать ничего, что не может сделать ваш пользователь, поэтому неэффективный процесс установки не может повредить вашу систему (кроме касания ваших файлов).

В Debian были улучшены инструменты сборки, чтобы больше не требовать этого, и вы можете собирать пакеты без них fakeroot . Это поддерживается dpkg непосредственно с помощью Rules-Requires-Root директивы (см. rootless-builds.txt ).

Чтобы понять назначение fakeroot и аспекты безопасности запуска от имени пользователя root или нет, это может помочь рассмотреть назначение упаковки. Когда вы устанавливаете часть программного обеспечения из источника, для использования в масштабе всей системы, вы делаете следующее:

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

Когда вы упаковываете часть программного обеспечения, вы откладываете вторую часть; но чтобы сделать это успешно, вам все равно нужно «установить» программное обеспечение в пакет, а не в систему. Поэтому, когда вы упаковываете программное обеспечение, процесс становится:

собрать программное обеспечение (без особых привилегий)
делать вид, что установил программное обеспечение (опять же без особых привилегий)
захватить установку программного обеспечения как пакет (то же самое)
сделать пакет доступным (то же самое)

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

fakeroot помогает с шагами 2 и 3, описанными выше, позволяя нам запускать процессы установки программного обеспечения и фиксировать их поведение, не работая от имени пользователя root.

@ ng.newbie Если вам нужно альтернативное объяснение: я вполне могу использовать шестнадцатеричный редактор, чтобы вручную создать файл tar, содержащий файлы, принадлежащие пользователю root, или с любыми другими возможными разрешениями. Это просто некоторая информация, в конце концов, она не имеет никакой силы, пока файл не существует в системе. @ ng.newbie Вы распаковываете его с помощью fakeroot или без fakeroot? @ ng.newbie, кроме того, если вы хотите создать тарбол с двоичным файлом suid-root для злонамеренных целей, вы можете сделать это на другом компьютере как настоящий root, а затем скопировать его в целевой объект. Нет необходимости в fakeroot там. fakeroot - это всего лишь инструмент, помогающий создавать tar-файл, он устраняет необходимость использования tar --mode --owner для каждого файла, добавляемого в архив (и работает также с другими программами). Потенциальные проблемы возникают, если / когда вы распаковываете недоверенный tar-файл или архив от имени root, а не при его создании.

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

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

Это на самом деле не повышает разрешения, это подделка. Он не позволяет вам делать что-либо (удалять, писать, читать), что вы не могли бы сделать иначе. Вы можете произвести пакет (теоретически) без него. Вы можете получить поддельный отчет ( ls ) без него.

Это не недостаток безопасности, потому что он не разрешает доступ или что-либо, что вы не можете сделать без него. Он работает без привилегий. Все это доза составляет перехватывать звонки на chown , chmod и т.д. Это делает их отсутствие операций, за исключением того, что он записывает то , что случилось бы. Он также перехватывает вызовы stat и т. Д., Поэтому он сообщает о разрешениях и владельце из собственной внутренней базы данных, как если бы были выполнены другие команды. Это полезно, потому что если вы затем заархивируете каталог, у него будут поддельные разрешения. Если вы затем распакуете как root, то разрешения станут реальностью.

Любые файлы, которые ранее не были доступны для чтения / записи, останутся недоступными для чтения / записи. Любые созданные специальные файлы (например, устройства) не будут иметь особых полномочий. Любой set-uid (другому пользователю), файлы не будут set-uid. Любое другое повышение привилегий не будет работать.

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

@ ctrl-alt-decor Как я и просил в приведенном выше комментарии, в * nix невозможно установить владельца как root от другого непривилегированного пользователя, правильно? Так что для этого должна быть веская причина, если программа это позволяет, как это не является недостатком безопасности? @ ctrl-alt-decor Fakeroot не позволяет мне читать / писать / удалять, но если я написал оболочку для системных вызовов, то вполне понятно, что я могу выполнять и эти операции. @ ctrl-alt-decor Таким образом, единственная причина существования fakeroot - установить права доступа к файлу с правами root, не будучи root. Если это не недостаток безопасности, то почему Linux вообще запретит это? Нет, это позволяет вам подделать настройки пользователя для любого пользователя, и подделать некоторые другие вещи. Попробуйте: запустите fakeroot и посмотрите на файлы извне, попробуйте получить доступ к файлам, чего не следует делать.

Здесь уже есть два хороших и очень подробных ответа, но я просто укажу, что вступительный абзац оригинальной fakeroot справочной страницы 1 действительно объясняет это довольно четко и кратко:

fakeroot запускает команду в среде, в которой, как представляется, он имеет привилегии root для манипулирования файлами. Это полезно для того, чтобы позволить пользователям создавать архивы (tar, ar, .deb и т. Д.) С файлами в них с правами root / владельцем. Без fakeroot нужно было бы иметь права суперпользователя для создания составных файлов архивов с правильными разрешениями и владельцем, а затем упаковать их, иначе придется создавать архивы напрямую, без использования архиватора.

Fakeroot позволяет пользователю без полномочий root создавать архивы, содержащие файлы, принадлежащие пользователю root, что является критически важной частью создания и распространения двоичных пакетов программного обеспечения в Linux. Без fakeroot этого архивы пакетов должны были бы быть сгенерированы при работе в качестве фактического root, чтобы они содержали правильное владение файлом и разрешения. Это было бы угрозой безопасности. Построение и упаковка потенциально ненадежного программного обеспечения является огромной угрозой, если оно выполняется с правами root. Благодаря fakeroot этому непривилегированный пользователь с непривилегированными файлами все еще может создавать архивы, содержащие файлы с правами суперпользователя. 2

Но это не угроза безопасности, потому что ничто в архиве на самом деле не принадлежит root до тех пор, пока файлы не будут извлечены . И даже в этом случае файлы будут извлечены с сохраненными корневыми правами, только если это сделает привилегированный пользователь. На этом этапе - когда fakeroot вспомогательный архив с «корневыми» файлами извлекается привилегированным пользователем - именно тогда «поддельный» корень наконец становится реальным. До этого момента никакие действительные привилегии суперпользователя никогда не получались и не игнорировались.

Примечания

Fakeroot породил некоторых конкурентов / имитаторов, которые будут маскироваться, как fakeroot если бы они были установлены, включая fakeroot-ng и pseudo . Но ИМХО ни на одной из страниц руководства «подражателя» не так ясно сказано, как правильно разобраться в этом вопросе. Палка с оригинальной, единственной fakeroot ОГ

Другие дистрибутивы / системы упаковки преодолевают это, просто не используя root-права в своих архивах пакетов. Например, в Fedora программное обеспечение может быть скомпилировано, установлено и упаковано непривилегированным пользователем без необходимости fakeroot . Все это делается в $HOME/rpmbuild/ пространстве пользователя , и обычно привилегированные шаги, такие как, make install перенаправляются (через механизмы, подобные --prefix и DESTDIR ) в $HOME/rpmbuild/BUILDROOT/ иерархию, которая может рассматриваться как своего рода «поддельное пространство» (без фактического использования fakechroot ).

Но даже во время make install все выполняется как и принадлежит непривилегированному пользователю. Владельцы извлеченных файлов и разрешения будут установлены по умолчанию root,root и 0644 (или 0755 для исполняемых файлов), если только они не будут переопределены в .spec файле определения пакета ( ); в этом случае они сохраняются как метаданные в конечном пакете. Поскольку никакие разрешения или владение фактически не применяются до процесса установки (привилегированного) пакета rpm, fakeroot во время упаковки не требуется ни root, ни необходимость. Но fakeroot на самом деле это просто другой путь к тому же результату.

Требования

1. UEFI вместо BIOS (выставить режим [UEFI only]);
2. OS 64-bit;
3. Linux (Kernel >= 3.3);

Установленный дистрибутив lubuntu-13.04-desktop-amd64 с выставленным режимом [UEFI only]. Отключил Fast Boot (После завершения можно включить).

Полученная таблица разделов

Необходимо обратить внимание на 1 раздел, с него и будет осуществляться прямая загрузка ядра без участия отдельного загрузчика (например GRUB 2), предъявляемые к нему требования:

Выставленный флаг boot;
Рекомендуемый размер до 512 МБ (встречал разные рекомендации каким он должен быть размером, в основном это 200-300 МБ, от себя замечу, что на деле он будет занят на 5.3 МБ);
Файловая система fat32/fat16/fat12 (UEFI имеет поддержку);

Подготовительные этапы выполнены, мы имеем работающую 64 битную операционную систему с выставленным режимом UEFI only и разделом для ядра (в данный момент там расположен GRUB, рядом мы положим ядро).

Получаем и настраиваем своё ядро

Загружаем ОС, открываем консоль.
Для того, чтобы ядро могло загрузиться без использования загрузчика, ему необходимо указать диск который будет монтироватся в качестве корневого, чтобы это сделать, нужно собрать своё ядро и указать ему опцию

у меня ОС установлена на диске sda2.
Обычно эту строку передаёт загрузчик GRUB вместе со многими другими параметрами

Получим необходимые инструменты (может занять продолжительное время)

Теперь создадим директорию в которой будем совершать все действия, я назову папку v2, что будет символизировать модификацию последнего ядра системы.

Получить исходники последней версии ядра и подготовить окружение

Перейдём в папку linux-3.8.0

Теперь приступим к модификации конфигурации ядра

После выполнения последней команды вначале будет выведено уведомление:

Здесь как раз указано, что редактируем конфигурацию для 64 битного ядра, вводим Y, жмём ввод и получим окно

теперь открываем поиск (клавиша '/'), вводим cmdline и жмём ввод и видим то, что на скриншоте

затем жмём цифру 2 и переходим к правке параметра 'Built-in kernel command line', жмём 'y' и в данном поле выставляется звёздочка, символизирующая, что данный режим включен, теперь переходим на поле которое ниже, жмём ввод и вводим в него заветное

Эта и есть та самая опция, ради которой всё затевалось (Вместо sda2 подставьте свой диск).
Мы получили данный конфиг:

На этом этапе я остановился, собрал ядро, порадовался, что всё так просто и при загрузке свежесобранного ядра получил ошибку, что ядро не может найти корневой раздел (собственно это, ради чего весь процесс сборки ядра и затевался). Я долго недоумевал что же к чему и даже попробовал указать диск в формате UUID, но стабильно получал ошибку:

и полученный вывод вставляем в окно ввода на сайте
Debian GNU/Linux device driver check page
жмём check, получаем:

из этого списка нам нужно включить драйвер дискового контроллера, в моём случае это ahci (Строка 'Sata Controller', Столбец 'Driver').
Снова жмём '/' для поиска и вводим 'ahci'. Для верности отмечаем все три найденных варианта для встраивания SATA_AHCI_PLATFORM, SATA_ACARD_AHCI и SATA_AHCI.

Теперь выбираем везде 'exit', в конце соглашаемся, сохраняем настройки выбором Yes. После чего в консоле отказываемся от редактирования конфигураций для других платформ, ибо они нам не нужны.

Сборка ядра

Теперь остаётся только подождать пока ядро будет собрано. В зависимости от мощности вашего компьютера зависит время сборки ядра, на моей машине процесс сборки занял чуть менее часа.

После сборки копируем полученное ядро на загрузочный раздел в папку 'EFI/boot', т.к раздел примонтирован к папке /boot/efi, в результате имеем путь /boot/efi/EFI/boot/

Теперь необходимо скопировать ядро в эту папку дав ему название bootx64.efi

Стоит отметить, что загрузка с использованием загрузчика GRUB всё равно будет доступна, стоит только переключить в UEFI (нажать del или F12 при загрузке). Это может пригодиться, если ядро по каким либо причинам не загрузилось.

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

Убедимся, что у Вас есть доступ к UEFI переменным

Если отработало без ошибок, делаем последний штрих. Добавим наше ядро в UEFI с приоритетом на загрузку №1, название в кавычках после --label можете ввести своё. Регистр в пути к загрузчику не имеет значения, т.к он не регистро-зависимый.

Теперь в меню загрузки UEFI добавлена новая строчка с названием 'Linux', которая осуществляет прямую загрузку ядра. На этом всё. Можно перезагрузить компьютер и убедиться, что ядро загружается минуя загрузчик.

Чтобы убедиться, что ядро загружено вами собранное, введите

Вы увидете список параметров, передаваемых ядру при загрузке (мы их сами указали ранее):

Цель достигнута! Спасибо за внимание!

UPD:
Спасибо пользователю ValdikSS за ценное замечание. Достичь поставленную цель можно гораздо проще. Пересобирать ядро в данном случае нет необходимости. Его можно скопировать на FAT раздел вместе с initrd (из дириктории /boot) и указать загрузчику правильные параметры:

Работает через LD_PRELOAD специальной библиотеки libfakeroot.so, которая переопределяет системные вызовы getuid, chown, chmod, mknod, stat, .

Часто применяется при сборке пакетов. Файлы, которыми якобы владеет root, попадают в архив tar или в deb-пакет с сохранением информации о владении. Распаковка этого архива будет делаться от имени настоящего root, и файлы займут свои места с правильными правами.

Чем отличается fakeroot от sudo? В первом случае происходит «симуляция root-окружения», во втором — «переключение в root-окружение».

Вроде одинаково? А вот и нет.

В первом случае whoami делает запрос на id пользователя, ядро ему отвечает 0, whoami говорит вам, что вы root.

Во втором случае whoami делает запрос на id пользователя, запрос перехватывается обёрткой fakeroot, обёртка отвечает 0, whoami говорит вам, что вы root. Но для ядра ваш id как был 1000 (допустим) так и остался.

К чему это приводит:

chroot

Операция изменения корневого каталога в Unix-подобных операционных системах. Программа, запущенная с изменённым корневым каталогом, будет иметь доступ только к файлам, содержащимся в данном каталоге. [2]

Изменение корневого каталога производится при помощи системного вызова chroot. Изменение корневого каталога затрагивает только текущий процесс (то есть процесс, сделавший системный вызов) и всех его потомков. Если требуется запустить некоторую программу с изменённым корневым каталогом, используют программу chroot. Эта программа принимает в качестве параметров новый корневой каталог и путь к программе. Она сначала сама выполняет вызов chroot для изменения собственного корневого каталога на указанный, а затем запускает программу по заданному пути. Так как изменённый корневой каталог наследуется потомками процессов, программа запускается с изменённым корневым каталогом.

Программа, корень которой был перенесён в другой каталог, не может обращаться к файлам вне этого каталога. Это обеспечивает удобный способ помещения в «sandbox» («песочницу») тестовой, ненадёжной или любой другой потенциально опасной программы. Это также простой способ использования механизма «jail» («тюрьмы»). Но наиболее часто chroot используется для сборки дистрибутивов или отдельных программ как бы в «чистой» среде.

Побег из chroot

Во многих системах очень просто за счёт /proc:

cgroups

Сокращение от control groups. Механизм ядра Linux, который ограничивает и изолирует вычислительные ресурсы (процессорные, сетевые, ресурсы памяти, ресурсы ввода-вывода) для групп процессов. [4]

Разработан в 2007 г., первая версия официально включена в ядро 2.6.24. Новая, переписанная версия cgroups v2 появилась в ядре 4.5 в 2016 г.

Механизм cgroups состоит из двух составных частей: ядра (cgroup core) и так называемых подсистем. Примеры подсистем:

blkio — устанавливает лимиты на чтение и запись с блочных устройств;
cpuacct — генерирует отчёты об использовании ресурсов процессора;
cpu — обеспечивает доступ процессов в рамках контрольной группы к CPU;
cpuset — распределяет задачи в рамках контрольной группы между процессорными ядрами;
devices — разрешает или блокирует доступ к устройствам;
freezer — приостанавливает и возобновляет выполнение задач в рамках контрольной группы
hugetlb — активирует поддержку больших страниц памяти для контрольных групп;
memory — управляет выделением памяти для групп процессов;
net_cls — помечает сетевые пакеты специальным тэгом, что позволяет идентифицировать пакеты, порождаемые определённой задачей в рамках контрольной группы;
netprio — используется для динамической установки приоритетов по трафику;
pids — используется для ограничения количества процессов в рамках контрольной группы.

Возможности

Механизм предоставляет следующие возможности:

ограничение ресурсов: использование памяти, в том числе виртуальной;
приоритизацию: разным группам можно выделить разное количество процессорного ресурса и пропускной способности подсистемы ввода-вывода;
учёт: подсчёт затрат тех либо иных ресурсов группой;
изоляцию: разделение пространств имён для групп таким образом, что одной группе недоступны процессы, сетевые соединения и файлы другой;
управление: приостановку (freezing) групп, создание контрольных точек (checkpointing) и их перезагрузку.

Использование

Управление в cgroups возможно различными способами:

через доступ к виртуальной файловой системе cgroup (по типу /proc) напрямую;
утилитами cgcreate, cgexec, cgclassify из доп. пакета

По сути, cgroups — это иерархическая файловая система, аналогичная /sys или /proc, которая предоставляет простой интерфейс доступа к внутренним механизмам распределения ресурсов в ядре.

Вывести список подсистем:

Каждая подсистема представляет собой директорию с управляющими файлами, в которых прописываются все настройки.

Для удобства можно поставить специальный пакет:

Пример: запрет записи в /dev/null

Примеры про ограничение скорости I/O: [5]

namespaces

Виртуализация

Виртуализация аппаратного обеспечения (Hardware virtualization)

Создание виртуального компьютера со своей операционной системой, который работает как настоящий.

Настоящую машину, на которой фактически работает виртуализация, называют host, виртуальную — guest. ПО для создания виртуальной машины называют hypervisor или Virtual Machine Manager.

Различают типы виртуализации аппаратного обеспечения.

Полная виртуализация — почти полная симуляция "железа", гостевое ПО работает без изменения.
Частичная виртуализация (например, виртуализация адресного пространства) — ныне не применяется, вытеснена полной.
Паравиртуализация — гостевые операционные системы подготавливаются для исполнения в виртуализированной среде, для чего их ядро незначительно модифицируется, гостевая ОС взаимодействует с гипервизором через специальное API.

В режиме полной виртуализации могут использоваться паравиртуальные драйверы для отдельных устройств (диск, сетевая карта, . ).

Примеры ПО для полной виртуализации: Parallels, VirtualBox, Virtual PC, Microsoft Hyper-V, VMware Workstation, VMware ESXi, QEMU.

Xen — кроссплатформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета (в 2003 г.). Поддерживает два режима виртуализации: паравиртуализация (PV) и аппаратная виртуализация (HVM). Большинство операционных систем могут быть запущены в режиме аппаратной виртуализации HVM. Список ОС, которые можно запустить в режиме паравиртуализации, ограничен.

Основной концепцией гипервизора Xen является домен. Доменом называется запущенная копия виртуальной машины. Домены бывают нескольких типов. Самые известные dom0 и domU. dom0 — первый запущенный Xen домен, обычно он автоматически создаётся и загружается сразу после загрузки и инициализации гипервизора. Этот домен имеет особые права на управление гипервизором и по умолчанию всё аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 — это место жизни ПО, управляющего Xen. dom0 всегда один. domU — рядовой домен (сокращение от User domain), содержащий в себе домен выполняющихся виртуальных машин. Обычно не имеет доступа к реальному оборудованию и является «полезной нагрузкой» системы виртуализации.

Xen запускается непосредственно на аппаратной платформе, но для своей работы требует управляющей операционной системы в dom0. Загрузка Xen осуществляется начальным загрузчиком типа GRUB или подобным. Непосредственно после загрузки Xen запускает операционную систему в dom0. В большинстве инсталляций в качестве ОС управляющего домена dom0 используется Linux.

KVM (Kernel-based Virtual Machine) — программное решение, обеспечивающее виртуализацию в среде Linux (2007) (также портировано на FreeBSD).

Программное обеспечение KVM состоит из загружаемого модуля ядра (называемого kvm.ko), предоставляющего базовый сервис виртуализации, и компонентов пользовательского режима (модифицированного QEMU).

Сам по себе KVM не выполняет эмуляции. Вместо этого программа, работающая в пространстве пользователя, использует интерфейс /dev/kvm для настройки адресного пространства гостя виртуальной машины, через него же эмулирует устройства ввода-вывода и видеоадаптер.

Виртуализация на уровне операционной системы

Метод виртуализации, при котором ядро операционной системы поддерживает несколько изолированных экземпляров пространства пользователя, вместо одного. Эти экземпляры (часто называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны реальному серверу. Для систем на базе UNIX эта технология может рассматриваться как улучшенная реализация механизма chroot. Ядро обеспечивает полную изолированность контейнеров, поэтому программы из разных контейнеров не могут воздействовать друг на друга.

Из преимуществ — малые или вообще отсутствующие накладные расходы на виртуализацию. Из недостатков — меньшая гибкость в выборе ОС (нельзя из Linux запустить Windows).

LXC (англ. Linux Containers) — система виртуализации на уровне ОС для запуска нескольких изолированных экземпляров Linux на одном узле. LXC не использует виртуальные машины, а создает виртуальное окружение с собственным пространством процессов и сетевым стеком. Все экземпляры LXC используют один экземпляр ядра операционной системы.

OpenVZ — ещё одна реализация технологии виртуализации на уровне ОС, которая базируется на ядре Linux. Проект развивался компанией Parallels. OpenVZ позволяет на одном физическом сервере запускать множество изолированных копий операционной системы, называемых «виртуальные частные серверы» (Virtual Private Servers, VPS) или «виртуальные среды» (Virtual Environments, VE).

Читайте также: