What is: Linux namespaces, примеры PID и Network namespaces

Данный пост обединяет в себе два других замечательных (на мой взгляд) поста на тему Namespaces в Linux — A Tutorial for Isolating Your System with Linux Namespaces и Introduction to Linux namespaces — Part 1: UTS, с небольшими дополнениями и изменениями. Тем не менее — крайне рекомендую к прочтению оба поста выше, и ознакомиться с другими ссылками из списка Ссылки по теме.

Введение

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

Ключевая функциональность ядра, которая позволяет добиться такой изоляции — Linux Namespaces, появилась в Linux начиная с версии 2.4.19 в 2002 году (CLONE_NEWNS), после чего с последующими обновлениями ядра добавлялись новые:

• UTS namespaces (CLONE_NEWUTS, Linux 2.6.19)
• IPC namespaces (CLONE_NEWIPC, Linux 2.6.19)
• PID namespaces (CLONE_NEWPID, Linux 2.6.24)
• Network namespaces (CLONE_NEWNET, добавлен в разработку в Linux 2.4.19, 2.6.24 и завершён в Linux 2.6.29)
• User namespaces (CLONE_NEWUSER, добавлен в разработку в Linux 2.6.23 и завершён в Linux 3.8)
• cgroup namespace (CLONE_NEWCGROUP, Linux 4.0)

см. Namespaces in operation.

Всякий, кто знаком с chroot в Linux уже имеет базовое представление о том, чего можно добиться с помощью Namespaces: аналогично тому, как chroot позволяет процессам видеть только определённую директорию как корень файловой системы — механизмы Linux namespaces позволяют выполнять операции изоляции в других механизмах операционной системы, такими как дерево процессов, сетевые интерфейсы, точки монтирования, IPC и так далее.

PID Namespace

Изначально Linux оддерживало только единое дерево процессов, в котором содержались ссылки на все запущенные в системе процессы в виде иерархического дерева. Любой процесс, при условии наличия соответствующих прав, мог подключиться к любому другому процессу и выполнить его трассировку или даже уничтожить его.

С появлением Linux Namespaces стало возможным иметь несколько «вложенных» друг в друга деревьев процессов: каждый процесс может иметь полностью изолированный набор процессов. С помощью этого достигается реальная изоляция процессов — процессы, принадлежащие к одному дереву процессов не могут подключиться или уничтожить процессы из дерева процессов другого, дочернего или родительского, процесса. По факту — эти процессы даже не имеют представления о том, что где-то есть другие такие процессы.

Каждый раз, когда компьютер с Linux запускается, он стартует с одного процесса с PID 1:

Этот процесс, в данном примере systemd(1), является корнем дерева процессов, и он инициализирует всю систему, запуская все остальные необходимые для её работы процессы, и все такие процессы запускаются в этом дереве ниже первого процесса.

Process Namespace позволяет создать новое дерево, с его собственным процессом с PID 1 — процесс, который создал такое дерево, остаётся в родительском пространстве имён, в основном дереве процессов, но его дочерний процесс становится корневым процессом собственного дерева процесса.

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

Кроме того, таким же образом возможно создавать вложенные простанства имён: один процесс порождает другой, дочерний, в новом PID namespace, а этот дочерний процесс порождает следующий, в ещё одном пространстве PID, и так далее.

С появлением PID namespaces один процесс может иметь несколько PID, по одному на каждый связанное с этим процессом пространство имён.

В исходном коде Linux, в файле pid.h, мы можем увидеть, что структура pid, которая ранее использовалась для отслеживания задач по одному PID, теперь использует структуру upid для отслеживания задач по нескольким PID:

...
/*
 * struct upid is used to get the id of the struct pid, as it is
 * seen in particular namespace. Later the struct pid is found with
 * find_pid_ns() using the int nr and struct pid_namespace *ns.
 */

struct upid {
  /* Try to keep pid_chain in the same cacheline as nr for find_vpid */
  int nr;
  struct pid_namespace *ns;
  struct hlist_node pid_chain;
};

struct pid {
  atomic_t count;
  unsigned int level;
  /* lists of tasks that use this pid */
  struct hlist_head tasks[PIDTYPE_MAX];
  struct rcu_head rcu;
  struct upid numbers[1];
};
...

см. PID namespaces in the 2.6.24 kernel.

Создание PID namespace: clone() и CLONE_NEWPID

Что бы создать новое пространство имён для PID — используем системный вызов clone() (другой вариант — использовать fork() и unshare()), которому аргументом передадим флаг CLONE_NEWPID.

После вызова clone() — новый процесс будет создан в новом пространстве имён PID, с новым деревом процессов.

Используем следующй код:

#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

static char child_stack[STACK_SIZE];

static int child_function() {

    printf("Child's PID from child_function() from own namespace: %d\n", getpid());
    return 0;
}

int main(int argc, char** argv) {

    pid_t pid = getpid(); 
    pid_t child_pid = clone(child_function, child_stack + STACK_SIZE, CLONE_NEWPID | SIGCHLD, NULL); 
 
    printf("PID for %s process = %d\n", argv[0], pid); 
    printf("Child process created by clone() from %s have PID = %d\n", argv[0], child_pid);
    waitpid(child_pid, NULL, 0);
    return 0;
}

Собираем, запускаем:

Кратко рассмотрим саму программу:

• static char child_stack[STACK_SIZE]: определяем размер стека для дочернего процесса
• pid_t pid = getpid(): определяем переменную pid типа pid_t, в которую заносим PID процесса, который выполняет саму программу pid_namespaces
• pid_t child_pid = clone(...): определяем переменную child_pid типаpid_t, которая получит значение PID из дочернего процесса, который создаётся вызовом clone()
• clone(child_function, child_stack + STACK_SIZE, CLONE_NEWPID | SIGCHLD, NULL): выполянем вызов clone(), которому передаём:
  • child_function: имя функции, которая будет выполнена дочерним процессом в новом namespace и выведет свой PID с помощью getpid()
  • child_stack: расположение стека для дочернего процесса
  • CLONE_NEWPID: собственно флаг для использования нового namespace при создании дочернего процесса
• printf("PID for %s process = %d\n", argv[0], pid): выводим имя программы pid_namespaces (argv[0]) и PID процесса программы pid_namespaces
• printf("Child process created by clone() from %s have PID = %d\n", argv[0], child_pid): выводим имя программы pid_namespaces, из которой вызывается clone() и PID дочернего процесса, созданного вызовом clone()

Итак — функция clone() порождает новый процесс, клонируя родительский, и начинает выполнение дочернего процесса с вызова функции child_function().

Однако, т.к. мы передали флаг CLONE_NEWPID — новый процесс запускается в собственном пространстве имён и создаёт новое дерево процессов, поэтому getpid() из child_function() возвращает нам Process ID равным единице, т.е. самый первый процесс в этом новом дереве.

Проверяем.

Изменим функцию child_function(), и к вызову getpid() (получить свой PID) — добавим вызов функции getppid() (Get Parent PID), в документации к которой сказано:

The getppid() function shall always be successful and no return value is reserved to indicate an error.

ОК:

...
static int child_function() {

    printf("Child's PID from child_function() from own namespace: %d\n", getpid());
    printf("Parent's PID from child_function() from own namespace: %d\n", getppid());
    return 0;
}
...

Собираем, проверяем:

Parent’s PID равен нулю, как и ожидали, т.к. child_function() запускается в собственном дереве и не видит родительского процесса вообще.

А теперь — изменим main() и вызов clone() в ней: уберём флаг CLONE_NEWPID:

...
pid_t child_pid = clone(child_function, child_stack + STACK_SIZE, SIGCHLD, NULL);
...

Пересобираем, запускаем:

Однако, у нас всё ещё нет полной изоляции: порожденный процесс до сих имеет доступ к другим общим ресусам системы.

Например, если бы дочерний процесс занимал порт 80 — это препятствовало бы любому другому процессу в системе использовать этот порт.

Network namespaces

Тут нам на помощь приходит Network namespaces, который позволяет каждому из создаваемых процессов видеть собственный набор сетевых интерфейсов.

Достигается это с помощью флага CLONE_NEWNET для функции clone().

Но прежде, чем продолжить с примерами на C — давайте попробуем испольтзовать iproute2 и создать NET namespaces вручную.

ip netns

Проверяем интерфейсы на хосте (в данном случае — это обычный ноутбук ThinkPad с Arch Linux):

Тут всё стандартно — loopback интефейс (lo0), ethernet — enp0s25, WiFi — wlp3s0 и пачка других.

Теперь — создадим новое пространство имён для сети:

И с помощью ip netns exec вызовем ip link list из созданного namespace:

Внутри созданного пространства доступен только интерфейс lo, при чём он в статусе DOWN, а не Up, как lo на хост-системе.

А для того, что бы получить возможность обращаться к устройствам в созданном NET Namespace — надо создать Point-to-Point туннель между хостом и «гостевой» системой, которая работала бы в в новом пространстве.

Для этого в Linux можно использовать виртуальные интерфейсы (veth — Virtual Ethernet), которые и используются в Docker для проброса трафика между хостом и создаваемыми контейнерами.

см. Docker Container Tutorial

veth создаёт два виртуальных интефейса — vent0 и veth1, которые затем связываются с пространством имён хост-системы и пространством имён в контейнере (которого у нас нет, но в Docker это происходит именно так).

Создаём пару veth:

Проверяем:

Вот наши два туннеля — veth1 => veth0, и обратный — veth0 => veth1.

Подключаем интерфейс veth1 в пространство имён demo:

Повторяем list из пространства demo, как мы делали в начале:

8: veth1@if9 — вот и новый интерфейс в пространстве имён demo.

Теперь настроим этот интерфейс, как делали бы это на любом другом.

Активируем loopback:

Активируем veth1:

Присваиваем IP 169.254.1.2 из сети 169.254.1.0/30 к veth1:

Поднимаем интерфейс veth0 на хосте:

И присваем ему IP 169.254.1.1 из сети 169.254.1.0/30:

Проверяем доступ между пространствами:

Таблица маршрутизации для 169.254.1.0/30:

Удаляем пару veth, что бы продолжить с примером на С:

Создание NET Namespace: clone()и CLONE_NEWNET

Теперь повторим всё то же, но из C программы, используя clone(), как в случае с PID namespace в начале поста, только с флагом CLONE_NEWNET вместо CLONE_NEWPID:

#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

static char child_stack[STACK_SIZE];

static int child_function() {

    printf("New NET namespace:\n\n");
    system("ip link list");
    printf("\n");
    return 0;
}

int main() {

    printf("\nOriginal NET namespace:\n\n");
    system("ip link list");
    printf("\n");

    pid_t child_pid = clone(child_function, child_stack + STACK_SIZE, CLONE_NEWPID | CLONE_NEWNET | SIGCHLD, NULL);
  
    waitpid(child_pid, NULL, 0);
    return 0;
}

Собираем, запускаем:

Всё отлично.

Обновим код, используем system() для вызова команд и настройки сети:

#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

#define STACK_SIZE (1024 * 1024)

static char child_stack[STACK_SIZE];

// sync primitive
int checkpoint[2];

static int child_function() {

    char c;

    // init sync primitive
    close(checkpoint[1]);

    // wait for network setup in parent
    read(checkpoint[0], &c, 1);

    // setup network
    system("ip link set lo up");
    system("ip link set veth1 up");
    system("ip addr add 169.254.1.2/30 dev veth1");

    printf("New NET namespace:\n\n");
    system("ip link list");
    printf("\n");

    // stay it UP to run ping
    sleep(500);
    return 0;
}

int main() {

    // init sync primitive
    pipe(checkpoint);

    pid_t child_pid = clone(child_function, child_stack + STACK_SIZE, CLONE_NEWPID | CLONE_NEWNET | SIGCHLD, NULL);

    // further init: create a veth pair
    char* cmd;

    asprintf(&cmd, "ip link set veth1 netns %d", child_pid);
    system("ip link add veth0 type veth peer name veth1");
    system(cmd);
    system("ip link set veth0 up");
    system("ip addr add 169.254.1.1/30 dev veth0");
    free(cmd);

    // signal "done"
    close(checkpoint[1]);

    printf("\nOriginal NET namespace:\n\n");
    system("ip link list");
    printf("\n");

    waitpid(child_pid, NULL, 0);
    return 0;
}

Собираем, запускаем:

Проверяем:

Ссылки на код — тут>>>.

Ссылки по теме

man7/namespaces

Introducing Linux Network Namespaces

Introduction to Linux namespaces — Part 1: UTS

A Tutorial for Isolating Your System with Linux Namespaces

Container Namespaces – Deep Dive into Container Networking

Network namespaces

Linux Network Namespace Introduction

Experiments with container networking

Containerization Mechanisms: Namespaces