При создании пользователя в среде hasher при помощи useradd, владелец файлов /etc/tcb/user/{shadow-,shadow.lock} выставляется как root:root, в то время как должен быть user:auth. У файла /etc/tcb/user/shadow владелец правильный. Команда useradd запускалась как 'useradd -M user' из скрипта в profile/hooks.d/ при создании кэша образа VPS для OpenVZ.
To proper package.
А хост система - i586 или x86_64 ?
i586. Год назад вело себя аналогично.
(In reply to comment #2) > А хост система - i586 или x86_64 ? i586 Попозже еще на x86_64 проверю.
confirmed
Дело даже не в обработке setfs[ug]id. fakeroot не обрабатывает open, поэтому не замечает, что файлы, созданные процессом с переключённым [ug]id, должны выглядеть как принадлежащие соответствующим [ug]id. Всё, что fakeroot обрабатывает для отслеживания [ug]id -- это семейство функций *chown*. Боюсь что эту задачу должен решать upstream.
Диагноз из комментария 6 в силе на fakeroot 1.29-alt3: wrapfunc.inp по-прежнему не оборачивает open/openat/creat, а setfsuid/setfsgid просто пробрасываются в ядро (libfakeroot.c: `return next_setfsuid(fsuid)`). Проверил в контейнере Sisyphus, `fakeroot sh -c 'useradd -M ftestuser'`: - внутри fakeroot все три файла /etc/tcb/ftestuser/{shadow,shadow-,shadow.lock} видны как root:root — именно эти права попадут в rpm или в образ; - реальные права на диске: shadow и shadow- получились ftestuser:auth (setfsuid отработал в ядре), shadow.lock — root:auth; - под настоящим root все три файла принадлежат пользователю: user:auth. То есть fakeroot не отслеживает владельца файлов, созданных с переключённым fsuid: libtcb выставляет владельца не через chown (который fakeroot перехватывает), а созданием файла под нужным fsuid. Чинить это надо в апстриме — обёртки open/openat/creat плюс учёт текущего fsuid в базе fakeroot. Оставляю открытым.
