Похоже на 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).