======== Системы: ======== Регулярки на Sisyphus (с mate и gnome) Workstation 10.1 (обновленный до sisyphus) =============== Версия пакетов: =============== podman-4.5.0-alt2.x86_64 shadow-submap-4.13-alt6.x86_64 ===================== Шаги воспроизведения: ===================== Выполнял по этой инструкции: https://www.altlinux.org/Podman 1) apt-get install podman fuse-overlayfs 2) sysctl kernel.unprivileged_userns_clone=1 echo 'kernel.unprivileged_userns_clone=1' >> /etc/sysctl.d/42-podman.conf 3) control newuidmap public control newgidmap public 5) usermod --add-subuids 100000-165536 --add-subgids 100000-165536 test 6) От пользователя test: podman system migrate podman info 7) Выполнить, как предлагается здесь: https://github.com/containers/podman/issues/12637#issuecomment-996715101 $ unshare -U sleep 100 & $ newuidmap $! 0 100000 65536 ; echo $? $ newgidmap $! 0 100000 65536 ; echo $? ========== Результат: ========== Шаг (6): ERRO[0000] running `/usr/bin/newuidmap 8171 0 1000 1 1 100000 65537`: Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1 Шаг(7): newuidmap и newgidmap завершается с exitcode = 1 ==================== Ожидаемый результат: ==================== Podman работает newuidmap и newgidmap возвращают exitcode 0 ============== Дополнительно: ============== На P10 при таких же шагах ошибка не воспроизводится
Похоже на local misconfiguration. Покажите, пожалуйста, вывод команды "id".
(Ответ для Dmitry V. Levin на комментарий #1) > Похоже на local misconfiguration. > Покажите, пожалуйста, вывод команды "id". $ id uid=500(test) gid=500(test) группы=500(test),10(wheel),100(users)
я думал я один такой. у меня такие же проблемы.
(Ответ для Alexandr Shashkin на комментарий #2) > (Ответ для Dmitry V. Levin на комментарий #1) > > Похоже на local misconfiguration. > > Покажите, пожалуйста, вывод команды "id". > > $ id > uid=500(test) gid=500(test) группы=500(test),10(wheel),100(users) Это на обновленном Workstation А это на регулярке Sisyphus: $ id uid=1000(test) gid=1000(test) группы=1000(test),10(wheel),14(uucp),19(proc),22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),100(users),966(camera),977(video),997(xgrp),998(scanner)
(In reply to Alexandr Shashkin from comment #0) > На P10 при таких же шагах ошибка не воспроизводится Чем отличается конфигурация p10, помимо версий пакета shadow-submap? Интересуют все отличия, которые могли повлиять, начиная с podman и заканчивая ядром. В первую очередь интересует, работает ли podman из p10 в связке с shadow-submap и ядром из Сизифа.
Вот это изменение https://git.altlinux.org/gears/s/shadow.git?p=shadow.git;a=commitdiff;h=5a0a7e1e2c7cb98f4167b3d1339f8b33748a9468 меняет условия в которых эти программы работают в том числе и в режиме public.
Эта утилита открывает /etc/login.defs на чтение которого у пользователя нет прав. openat(AT_FDCWD, "/etc/login.defs", O_RDONLY)
(Ответ для Gleb F-Malinovskiy на комментарий #7) > Эта утилита открывает /etc/login.defs на чтение которого у пользователя нет > прав. > openat(AT_FDCWD, "/etc/login.defs", O_RDONLY) Да, добавление пользователя в группу shadow решило проблему.
(In reply to Gleb F-Malinovskiy from comment #6) > Вот это изменение > https://git.altlinux.org/gears/s/shadow.git?p=shadow.git;a=commitdiff; > h=5a0a7e1e2c7cb98f4167b3d1339f8b33748a9468 > меняет условия в которых эти программы работают в том числе и в режиме > public. Это однозначно причина регрессии.
> Это однозначно причина регрессии. Отчасти. Видимо есть что-то еще. Сейчас попробовал воспроизвести в p10, но в правилах control использовал свои изменения (с применением capabilities). Ошибка не воспроизвелась. Я могу откатить в сизифе свои изменения или поставить setuid в public mode, но это исправит только часть проблемы.
Да, похоже что открывать login.defs он стал только после вот этого коммита: https://github.com/shadow-maint/shadow/commit/c464ec55709dc931ba2f24073b8b1a86d5209ab0
(In reply to Gleb F-Malinovskiy from comment #11) > Да, похоже что открывать login.defs он стал только после вот этого коммита: > https://github.com/shadow-maint/shadow/commit/ > c464ec55709dc931ba2f24073b8b1a86d5209ab0 По идее, коммит "Relax gid checking" не должен был ухудшить ситуацию, так что непонятно, это ли открывание влияет и почему.
(In reply to Dmitry V. Levin from comment #12) > (In reply to Gleb F-Malinovskiy from comment #11) > > Да, похоже что открывать login.defs он стал только после вот этого коммита: > > https://github.com/shadow-maint/shadow/commit/ > > c464ec55709dc931ba2f24073b8b1a86d5209ab0 > > По идее, коммит "Relax gid checking" не должен был ухудшить ситуацию, так > что непонятно, это ли открывание влияет и почему. OK, теперь понятно, getdef_bool() просто делает exit(1), когда не может открыть login.defs, так что да, после этого коммита несуидные newuidmap/newgidmap больше не работают. Надо либо дать этим утилитам прав, либо вернуть suid.
(In reply to Nikolay Burykin from comment #10) > Я могу откатить в сизифе свои изменения или поставить setuid в public mode, > но это исправит только часть проблемы. Про часть проблемы я не понимаю. Вы видите какую-то ещё проблему? cap_setgid+ep недостаточно для работы shadow 4.13 потому что он открывает на чтение файл /etc/login.defs (права на который 0640 root:root), а если не может открыть его, делает exit 1. В любом случае, пакет в Сизифе нужно исправить.
(Ответ для Gleb F-Malinovskiy на комментарий #14) > (In reply to Nikolay Burykin from comment #10) > > Я могу откатить в сизифе свои изменения или поставить setuid в public mode, > > но это исправит только часть проблемы. > > Про часть проблемы я не понимаю. Вы видите какую-то ещё проблему? > cap_setgid+ep недостаточно для работы shadow 4.13 потому что он открывает на > чтение файл /etc/login.defs (права на который 0640 root:root), а если не > может открыть его, делает exit 1. Нет. Тут неправильная формулировка. Под проблемой я имел ввиду изменение, которое привело к тому, что cap_setgid+ep стало недостаточно (потому что в p10 и c10 его достаточно). Мне не очень было понятно почему, но ваш анализ изменений в апстриме, приведеный ранее, всё разъяснил. В любом случае это изначально было больше риторическое обращение. Очевидно, что стоило уделить больше внимания тестированию правил не только в p10 и c10, но и в Сизифе. > В любом случае, пакет в Сизифе нужно исправить. Разумеется. Это всё еще можно решить с помощью capabilities, исправив правило public для newuidmap/newgidmap на: new_fmode public 711 root root 'cap_setuid,cap_dac_read_search+ep' то есть убрав проверку прав на чтение для этих утилит. Исправление подготовлю.
Почему вы не хотите дать права на чтение login.defs ? Это же решает проблему. Что такого в login.defs, что его нельзя читать обычным пользователям ?
(Ответ для Anton Farygin на комментарий #16) > Почему вы не хотите дать права на чтение login.defs ? Это же решает > проблему. Что такого в login.defs, что его нельзя читать обычным > пользователям ? Если вопрос ко мне, то я не предлагаю потому что такой режим вроде как "исторически сложился" для этого файла, и наверное на это есть причины (хотя мне тоже очень интересно было бы узнать какие). Но если объективных причин с точки зрения безопасности нет, то полностью согласен o+x на /etc/login.defs намного проще решает проблему чем дополнительные capabilities на newuidmap/newgidmap, и тем более SUID на них же.
(In reply to Anton Farygin from comment #16) > Почему вы не хотите дать права на чтение login.defs ? Это же решает > проблему. Что такого в login.defs, что его нельзя читать обычным > пользователям ? Ответить на этот вопрос на порядки сложнее: надо как минимум проверить, что * никто не использует login.defs для блокировок, * информация из login.defs не может быть использована потенциальным злоумышленником, т.е. надо смотреть на каждый параметр и взвешивать, как его значение может быть использовано.
Так давайте пойдём таким путём ? у нас, насколько я помню, это уже не первое место где вылезает отсутствие доступа к login.defs. Ещё, наверное, можно пойти по пути разделения login.defs на те, которые действительно требуются для чтения и не представляют опасности и на те, которые явно не нужны для работы и можно закрыть. Но это выглядит сложнее, т.к. я не уверен что все читают login.defs через один и тот же интерфейс.
(In reply to Anton Farygin from comment #19) > Так давайте пойдём таким путём ? у нас, насколько я помню, это уже не первое > место где вылезает отсутствие доступа к login.defs. Давайте не будем подменять простую задачу более сложной. Если хочется открыть login.defs на чтение, давайте решать эту задачу отдельно.
(In reply to Nikolay Burykin from comment #15) > Это всё еще можно решить с помощью capabilities, исправив правило public для > newuidmap/newgidmap на: > > new_fmode public 711 root root 'cap_setuid,cap_dac_read_search+ep' Давайте так и сделаем.
(Ответ для Alexandr Shashkin на комментарий #0) > ==================== > Ожидаемый результат: > ==================== > Podman работает > newuidmap и newgidmap возвращают exitcode 0 Попробуйте пакет с исправлением ошибки из задания: https://packages.altlinux.org/ru/tasks/323417/ # apt-repo test 323417 Проверил у себя на чистой инсталляции Сизифа, ошибка не повторилась.
shadow-1:4.13-alt7 -> sisyphus: Wed Jun 21 2023 Nikolay Burykin <bne@altlinux> 1:4.13-alt7 - newuidmap/newgidmap: Added cap_dac_read_search to all modes (ALT #46462).
