моментално изпълнение

(ch)root файлова система и малко магия

Нека започнем с най-важния факт:Главната файлова система не е файловата система на хост операционната система.Използването на хост файловата система ще доведе до несъвместимост. Очевидните са: различни основни библиотеки, потенциално различни файлови оформления.

Core snap променя основната файлова система за средата за изпълнение на дадено приложение. Можете да мислите за това като за chroot, просто имайте предвид, че snap файловите системи са само за четене и основните snap-ове не са изключение.

Някои директории в основния snap са монтирани (можете да мислите за тях като специален тип символна връзка или твърда връзка към директория, въпреки че и двете сравнения са неточни) към някои места в хост системата:

Имайте предвид, че няма пътеки /usr/lib/ или /usr/bin/.Ако програма в snap се нуждае от библиотека или двоичен файл, тогава необходимият трябва да присъства в този snap пакет.Единственото изключение са библиотеки от ниско ниво като libc, които са в основния snap.

С всички тези монтирания и chroot-ове, някой може да се чуди как изглеждат тези точки на монтиране за всички други процеси в системата? Отговорът е лесен. Изглеждат сякаш няма нищо конкретно свързано със snappy.

За да разберете отговора, трябва да знаете малко за пространствата от имена на Linux. Пространствата от имена са способността да се създаде отделен изглед на различни аспекти на Linux системите на ниво всяко приложение. Вместо виртуални машини, които емулират единичен компютър с възможност за стартиране на различна операционна система, пространствата от имена са леки. Snappy използва само едно от наличните пространства от имена, пространството от имена за монтиране. няма да го направяЗа да ви заблудя, докато идеята изглежда проста - "точките за монтиране вътре в пространството на имената са изолирани от точките извън", в действителност всичко е по-сложно поради "споделени поддървета" (shared-subtrees). Една от интересните последици от използването им е, че монтираното, например /медия/, е видимо само за дадено приложение, например VLC, а не обратното. Ако злонамерен snap се опита да монтира нещо в, да речем, /usr/ въпреки различните механизми за сигурност, промените ще бъдат видими само за процеса в този snap.

Не се притеснявайте, ако все още не разбирате напълно темата. Основното е, че вашето приложение вижда различно представяне на файловата система, но тази визия е последователна в различните Linux дистрибуции.

Помислете за няколко точки, без подробно обяснение:

Всеки процес получава свой собствен частен /tmp/ с нов tmpfs. Това е за безопасност. Проста последица от това е, че не можете да споделяте файлове през тази временна директория и не можете да създавате огромни файлове, тъй като tmpfs има ограничение, свързано с наличната RAM.
Собствено копие на /dev/pts/ с терминални емулатори. Това е друга мярка за сигурност. На практика няма много поводи за притеснение.
Цялата файлова система на хоста е монтирана в /var/lib/snapd/hostfs. Това може да се използва в интерфейси като интерфейса за споделяне на съдържание, например. За това супер интересно нещо ще стане дума в отделна статия.
Специален код за поддръжка на собствени драйвери на Nvidia. Една интересна тема за разработчиците на игри също ще бъде разгледана в отделна статия.
Може да се окаже невъзможно да запазите текущата работна директория чрез цялата тази магия на chroot, mount и bind-mount. Лесен начин за проверка е например да създадете директория/tmp/foo/ и опитайте да изпълните всяка команда snap от там. Най-лесният начин да изпитате това е да създадете директория в /tmp (напр. /tmp/foo) и да се опитате да изпълните всяка команда snap там. Поради частната (и празна) директория /tmp директорията /tmp/foo не съществува за процеса на прилагане на snap. Snap-confine ще покаже информационно съобщение и няма да откаже да стартира.

В този момент има познати места за програмата и те съдържат познати за тази програма данни. Това не означава, че тези директории могат да се четат или записват! Те просто присъстват и механизмът за ограничаване и интерфейсите ще решат какво ще бъде налично за четене или писане. И тук стигаме до такава част като snap-confine.

Ограничителен механизъм на процеса

Snap-confine поддържа две технологии за пясъчник: филтрите за системни повиквания seccomp и системата за задължителен достъп AppArmor.

Seccomp ограничава програмата до списъка със системни извиквания, достъпни за нея, които сами по себе си са интерфейс между ядрото на Linux и потребителското пространство. Много грубо казано, някои функции в езиците за програмиране се изпълняват като системни повиквания и seccomp е подсистемата на Linux, която отговаря за достъпа до тях.

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

В режим на строго ограничаване, наречен строг, опитите на програма да използва системни извиквания, които не са й разрешени, ще доведат до нейното убиване. Системният дневник щепоказва нещо като:

Процесът с PID=66834 беше убит със сигнал 31 (SIGSYS), защото се опита да използва номер на системно повикване 54 (setsockopt). Номерата на системните повиквания зависят от архитектурата, примерът предполага 64-битова архитектура (amd64).

Дори ако системното повикване е разрешено, определена операция може да бъде деактивирана в AppArmor. Например пясъчната среда е настроена така, че програмите да могат да пишат в пътеки от $SNAP_USER_DATA (или $SNAP_DATA за демон услуги). И въпреки че $SNAP_USER_DATA физически сочи към

/snap/$app-name/$revision/, но четенето и писането в реалната домашна директория на потребителя е деактивирано по подразбиране.

Виждаме, че процесът PID=67013 се е опитал да отвори ключовия файл /home/zyga/.ssh/authorized_keys и му е отказана операцията за четене (denied_mask="r"). Ако програмата е инсталирана в режим за разработка, тогава действието ще бъде разрешено, като информацията ще бъде регистрирана.

Последното нещо, което snap-confine прави, е да създаде .

група за управление на устройството

Създават се Cgroups за устройства и в тях се премества процесът на кандидатстване. Cgroups е малка колекция от типични /dev/null устройства и допълнителни, но изрично посочени устройства. Това се прави с помощта на правилата на UDEV, маркиращи подходящи устройства. За да завършите картината, заслужава да се отбележи, че няма нужда да зареждате специално тази тема. Ако възникне необходимост, ще разгледаме тази тема подробно и ще покажем как можете да я използвате, за да опростите справянето с определени ситуации. По подразбиране групите за управление на устройството не се използват.

И сега всичко е накуп

С това казано, snap-confine извиква чрез execv обвиващ скрипт, който съдържа извикване на програмата, посочена от snapcrafter във файла snapcraft.yaml в разделаприложения Пример

Ограничителният механизъм snap-confine се извиква при всяко стартиране на програмата. За повече информация вижте man 5 snap-confine Следващия път ще създадем нашия първи изключително прост интерфейс.