Summary: | newuidmap и newgidmap завершаются с exitcode 1 | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Alexandr Shashkin <dutyrok> |
Component: | shadow-submap | Assignee: | bne <bne> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | bne, burykinne, glebfm, ldv, legion, rider, sem, shaba |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux |
Description
Alexandr Shashkin
2023-06-09 17:22:38 MSK
Похоже на 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). |