Исправление intelfx, (текущая версия) :
http://0pointer.net/blog/dynamic-users-with-systemd.html отлично манипулирует uid фактически ничего на диске не трогая
Леннарт там специально пишет, что механизм DynamicUsers= обходит проблему владения файлами на диске, просто не давая процессу ничего писать на диск.
скомбинировать какие-то функции этого с https://www.freedesktop.org/software/systemd/man/systemd-mount.html чтобы просто маппить uid/gid из ФС с uid/gid текущего пользователя аналогично трасляции, используемой для непривилигерованных контейнеров?
User namespaces — это, конечно, трансляция, но она здесь совсем никак не подходит. Во-первых, она работает в обратную сторону, т. е. на диске у тебя UID вида OFFSET + 1000, а в памяти UID 1000, при этом упор на то, чтобы можно было иметь одновременно несколько разных «UID 1000» в памяти (соответствующих разным OFFSET’ам на диске).
А нужно наоборот, на диске UID стабильный (типа 1000), а в памяти может быть любой, в зависимости от того, сколько юзеров сейчас на данной машине есть, с фокусом на то, чтобы можно было иметь одновременно несколько разных UID 1000 на диске, отображающихся в разные UID’ы в памяти.
Во-вторых, даже если пытаться натянуть сову на глобус и заюзать user namespaces, то трансляция там линейная, т. е. тебе придётся под каждый хомяк на этапе создания хомяка псевдослучайно выделять 2^16 UID’ов и надеяться, что они не пересекутся (пространство всего-навсего 2^32, это тебе не UUID’ы, в которых уникальность достигается тупо статистически). Но если ты уже решил эту задачу, то никакая трансляция в принципе не нужна — можно просто динамически синтезировать password file entry с нужным UID’ом и всё. Проблема как раз в том, что 2^32 UID’ов слишком мало.
Ну и в-третьих, если ты засунешь пользовательские процессы в user namespace, то сломается примерно всё. Например, файлы, которыми владеет рут или любой другой пользователь, будут выглядеть как nobody:nobody.
Короче, эта сова начинает рваться ещё в самом начале процесса.
Интересно почему это нужно именно на уровне ФС делать?
Очевидно, потому что нам нужно транслировать UID’ы между диском и памятью в зависимости от пути до файла.
Исходная версия intelfx, :
http://0pointer.net/blog/dynamic-users-with-systemd.html отлично манипулирует uid фактически ничего на диске не трогая
Леннарт там специально пишет, что механизм DynamicUsers= обходит проблему владения файлами на диске, просто не давая процессу ничего писать на диск.
скомбинировать какие-то функции этого с https://www.freedesktop.org/software/systemd/man/systemd-mount.html чтобы просто маппить uid/gid из ФС с uid/gid текущего пользователя аналогично трасляции, используемой для непривилигерованных контейнеров?
User namespaces — это, конечно, трансляция, но она здесь совсем никак не подходит. Во-первых, она работает в обратную сторону, т. е. на диске у тебя UID вида OFFSET + 1000, а в памяти UID 1000, при этом упор на то, чтобы можно было иметь одновременно несколько разных «UID 1000» в памяти (соответствующих разным OFFSET’ам на диске).
А нужно наоборот, на диске UID стабильный (типа 1000), а в памяти может быть любой, в зависимости от того, сколько юзеров сейчас на данной машине есть, с фокусом на то, чтобы можно было иметь одновременно несколько разных UID 1000 на диске, отображающихся в разные UID’ы в памяти.
Во-вторых, даже если пытаться натянуть сову на глобус и заюзать user namespaces, то трансляция там линейная, т. е. тебе придётся под каждый хомяк на этапе создания хомяка псевдослучайно выделять 2^16 UID’ов и надеяться, что они не пересекутся (пространство всего-навсего 2^32, это тебе не UUID’ы, в которых уникальность достигается тупо статистически). Но если ты уже решил эту задачу, то никакая трансляция в принципе не нужна — можно просто динамически синтезировать password file entry с нужным UID’ом и всё. Проблема как раз в том, что 2^32 UID’ов слишком мало.
Ну и в-третьих, если ты засунешь пользовательские процессы в user namespace, то сломается примерно всё. Например, файлы, которыми владеет рут или любой другой пользователь, будут выглядеть как nobody:nobody.
Интересно почему это нужно именно на уровне ФС делать?
Очевидно, потому что нам нужно транслировать UID’ы между диском и памятью в зависимости от пути до файла.