Наконец-то мы добрались до момента, когда готовы обсуждать контейнеризацию с позиции изоляции файловой системы! Не будем тянуть - попробуем запустить контейнер в новом mount namespace через unshare с флагом --mount:
root@backend:/home/alexzhaba# ls
secret_folder
root@backend:/home/alexzhaba# ls /proc/$$/ns/mnt -al
lrwxrwxrwx 1 root root 0 Jun 22 14:02 /proc/727168/ns/mnt -> 'mnt:[4026531841]'
root@backend:/home/alexzhaba# unshare --mount bash
root@backend:/home/alexzhaba# ls
secret_folder
root@backend:/home/alexzhaba# ls /proc/$$/ns/mnt -al
lrwxrwxrwx 1 root root 0 Jun 22 14:03 /proc/728193/ns/mnt -> 'mnt:[4026532786]'
Опять непруха! Mount namespace стал новым, но при этом та самая питонячая sectet_folder все еще видна в моем, казалось бы, изолированном процессе! Давайте поразмышляем: что мы ожидали получить от такого запуска unshare? Скорее всего мы ожидали увидеть совсем другую файловую систему, как будто бы полностью чистую… Но кто указывает, какая файловая система должна быть? Например, когда мы используем Dockerfile, у нас есть возможность указать с помощью инструкции FROM разные варианты:
FROM ubuntu:20.04
FROM alpine:3.14
...
И ведь у каждого такого образа разный набор файлов! Какой нужен нам? Может быть внутри линукса можно так взять и получить "базовый линукс"? Появляется очень много неоднозначных вопросов, которые мы бы хотели задать команде unshare, при этом эти вопросы имеют прикладной характер в условиях использования относительно низкоуровневого API. Точно ли все это должно быть определено по умолчанию в unshare? Или имеется какой-то более гибкий механизм изоляции файловой системы? Тут самое время для еще одного лиричного отступления, которое, к счастью или сожалению, будет еще больше, чем про процессы.