54283 2025-05-15 12:12:19 +0300 mkhomedir_helper ошибка при выставлении прав на каталог. 2025-06-02 17:49:07 +0300 1 1 4 Development Sisyphus pam unstable e2k Linux ASSIGNED P5 normal --- 1 nik mike glebfm ilyakurdyukov ldv mike placeholder vt qa-sisyphus oldest_to_newest 264826 0 nik 2025-05-15 12:12:19 +0300 Обнаружилась проблема в ALT Server 10.2. При попытке зайти под LDAP-учетной записью в первый раз, вылетает ошибка: Could not chdir to home directory: Permission Denied Попытка решить проблему привела к утилите mkhomedir_helper. Именно данная утилита отвечает за создание домашних директорий в модуле pam_mkhomedir. Данная утилита не хочет менять владельца у директории /home/$USER, и у всех директорий, которые расположены в /etc/skel. При этом обычные файлы из /etc/skel в домашнюю дир-ю переносятся корректно, со сменой владельца. В логах systemd следующая картина: PAM unable to changes perms on directory /home/$USER/.ssh: Operation not supported PAM unable to changes perms on directory /home/$USER: Operation not supported PAM failed: Permission denied Для локального пользователя попытка создать дом-юю дир-ю утилитой mkhomedir_helper заканчивается тем же результатом: Дир-я создана, но владельцем остается root. Файл /sbin/mkhomedir_helper принадлежит пакету pam-1.6.1-alt1.E2K.1.e2kv5 Файл бинарный, поэтому детали посмотреть проблематично. Для теста: создаем локального пользователя test useadd test Проверяем, и если есть, удаляем его домашний каталог. (rm -rf /home/test) Запускаем: mkhomedir_helper test ; echo $? Смотрим содержимое: ls -la /home/test Если в /etc/skel есть каталоги, то будут файлы до первого каталога. Файлы будут иметь правильного владельца, каталог будет иметь владельца root. Если из /etc/skel убрать все каталоги, то все файлы будут скопированы нормально, но владелец домашнего каталога останется root. В journalctl фиксируется событие: May 14 21:00:47 alt-16c mkhomedir_helper[84656]: PAM unable to change perms on directory /home/test: Operation not supported Но по strace я не увидел что бы на каком-то системном вызове возникала ошибка. То ли в самом бинарнике ошибка, то ли что-то с настройками не доделали. Но без исходника – только гадать. 264831 1 mike 2025-05-15 12:26:32 +0300 (Ответ для nik на комментарий #0) > Файл /sbin/mkhomedir_helper принадлежит пакету pam-1.6.1-alt1.E2K.1.e2kv5 Посмотрел -- сборка отличается от pam-1.6.1-alt1 патчем МЦСТ, поскольку на эльбрусе несколько стеков; возможно, надо патчить и mkhomedir. Илья, гляньте, вдруг получится нашими силами что-то тут понять. 264853 2 ldv 2025-05-15 13:41:32 +0300 (In reply to nik from comment #0) > В journalctl фиксируется событие: > May 14 21:00:47 alt-16c mkhomedir_helper[84656]: PAM unable to change perms > on directory /home/test: Operation not supported > > Но по strace я не увидел что бы на каком-то системном вызове возникала > ошибка. > > То ли в самом бинарнике ошибка, то ли что-то с настройками не доделали. Но > без исходника – только гадать. В апстримном PAM этот код выглядит следующим образом: if (fchmodat(parent->fd, dest, dir_mode, AT_SYMLINK_NOFOLLOW) != 0 || fchownat(parent->fd, dest, pwd->pw_uid, pwd->pw_gid, AT_SYMLINK_NOFOLLOW) != 0) { pam_syslog(NULL, LOG_DEBUG, "unable to change perms on directory %s/%s: %m", parent->path, dest); retval = PAM_PERM_DENIED; } Если у вас работает этот код, то я бы предположил, что проблема либо в ядре, либо в libc. 264915 3 nik 2025-05-15 21:00:46 +0300 В переданных исходниках работает такой код: if (fchmodat(parent->fd, dest, dir_mode, AT_SYMLINK_NOFOLLOW) != 0 || fchownat(parent->fd, dest, pwd->pw_uid, pwd->pw_gid, AT_SYMLINK_NOFOLLOW) != 0) Был написан небольшой тест, который вызывает данный вызов и проверен на alt 10.2 SP (8СВ) - glibc 2.29 ( Эльбрус) redhat 9.5 - glibc 2.34 (x86) На x86 тестовый код отрабатывает без ошибок, на эльбрусах вызов fchmodat вызыват ошибку : Operation not supported Обнаружено, что в redhat в файле mkhomedir_helper.c не используются вызовы функций fchownat и fchmodat. вместо них используются chown и chmod if (chmod(dest, 0777 & (~u_mask)) != 0 || chown(dest, pwd->pw_uid, pwd->pw_gid) != 0) Ошибку можно исправить, используя вместо fchownat и fchmodat - chown и chmod соответственно. Тестовый файл в attach. 264916 4 18474 nik 2025-05-15 21:01:48 +0300 Created attachment 18474 тестовый пример 264921 5 ldv 2025-05-16 04:33:13 +0300 (In reply to nik from comment #3) > В переданных исходниках работает такой код: > > if (fchmodat(parent->fd, dest, dir_mode, AT_SYMLINK_NOFOLLOW) != 0 || > fchownat(parent->fd, dest, pwd->pw_uid, pwd->pw_gid, > AT_SYMLINK_NOFOLLOW) != 0) > > > Был написан небольшой тест, который вызывает данный вызов и проверен на > alt 10.2 SP (8СВ) - glibc 2.29 ( Эльбрус) > > redhat 9.5 - glibc 2.34 (x86) > > На x86 тестовый код отрабатывает без ошибок, на эльбрусах вызов fchmodat > вызыват ошибку : Operation not supported Очевидно, ошибка специфична для эльбруса, точнее говоря, для связки тамошних kernel+glibc, поскольку в тестовом примере ничего, кроме них и компилятора, не используется. Для справки, вот апстримный коммит из PAM v1.6.0, от которого на эльбрусе такие сложности: https://github.com/linux-pam/linux-pam/pull/638/commits/12e829094b0ee4f16b716285684e1a0df4541910 Полагаю, что багрепорт можно смело перевешивать с пакета pam на эльбрус. 264940 6 mike 2025-05-16 10:50:43 +0300 Благодарю за разбор; упомянутый коммит откатывать даже под %ifarch %e2k неохота в силу полезности изменения, повесил mcst#9485 с выдержкой и примером отсюда. Воспроизводится на текущих ядре 5.10-1.40 и glibc 2.29-26.020 из p10_e2k; не воспроизводится на 6.1-1.2 и 2.35-2.29.006 из нынешнего sisyphus_e2k. 266300 7 mike 2025-06-02 17:22:24 +0300 Ответ МЦСТ: --- Данные функции реализованы в ванильном glibc, начиная с glibc-2.32. --- Здесь вылезла интересная коллизия: в p10 именно glibc 2.32, а в p10_e2k -- 2.29 (сообразно доступной стабильной версии системы программирования на момент решения по выбору/обновлению оной). Видимо, для p10_e2k придётся форкнуть pam, откатив конкретно этот коммит. 266309 8 mike 2025-06-02 17:49:07 +0300 (Ответ для Michael Shigorin на комментарий #7) > Видимо, для p10_e2k придётся форкнуть pam, откатив конкретно этот коммит. Поправочка: он и так форк, а коммиты (7 шт по апстримной issue 638) так просто не откатить уже; придётся разбираться. 18474 2025-05-15 21:01:48 +0300 2025-05-15 21:01:48 +0300 тестовый пример test-chown.c text/plain 1894 nik I2RlZmluZSBfR05VX1NPVVJDRQ0KI2luY2x1ZGUgPHB3ZC5oPg0KI2luY2x1ZGUgPGdycC5oPg0K I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8dW5pc3Rk Lmg+DQojaW5jbHVkZSA8ZmNudGwuaD4gICAgICAvLyDQlNC70Y8gQVRfRkRDV0QNCiNpbmNsdWRl IDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRlIDxzeXMvc3RhdC5oPg0KI2luY2x1ZGUgPHN0cmluZy5o Pg0KI2luY2x1ZGUgPGVycm5vLmg+DQoNCmludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10p IHsNCiAgICB1aWRfdCB1aWQ7DQogICAgZ2lkX3QgZ2lkOw0KICAgIHN0cnVjdCBwYXNzd2QgKnB3 ZDsNCiAgICBjaGFyICplbmRwdHI7DQoNCiAgICBpZiAoYXJnYyAhPSA0IHx8IGFyZ3ZbMV1bMF0g PT0gJ1wwJykgew0KICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlVzYWdlOiAlcyA8b3duZXI+IDxm aWxlPiA8bW9kZT5cbiIsIGFyZ3ZbMF0pOw0KICAgICAgICBleGl0KEVYSVRfRkFJTFVSRSk7DQog ICAgfQ0KDQogICAgLy8g0J/QvtC70YPRh9Cw0LXQvCBVSUQgKNC4IEdJRCkg0L/QvtC70YzQt9C+ 0LLQsNGC0LXQu9GPDQogICAgdWlkID0gc3RydG9sKGFyZ3ZbMV0sICZlbmRwdHIsIDEwKTsNCiAg ICBpZiAoKmVuZHB0ciAhPSAnXDAnKSB7DQogICAgICAgIHB3ZCA9IGdldHB3bmFtKGFyZ3ZbMV0p Ow0KICAgICAgICBpZiAocHdkID09IE5VTEwpIHsNCiAgICAgICAgICAgIHBlcnJvcigiZ2V0cHdu YW0iKTsNCiAgICAgICAgICAgIGV4aXQoRVhJVF9GQUlMVVJFKTsNCiAgICAgICAgfQ0KICAgICAg ICB1aWQgPSBwd2QtPnB3X3VpZDsNCiAgICAgICAgZ2lkID0gcHdkLT5wd19naWQ7DQogICAgfSBl bHNlIHsNCiAgICAgICAgLy8g0JXRgdC70Lgg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GMINGD0LrQ sNC30LDQvSDQutCw0LogVUlEIOKAlCDQv9C+0LvRg9GH0LDQtdC8IEdJRCDRh9C10YDQtdC3IGdl dHB3dWlkDQogICAgICAgIHB3ZCA9IGdldHB3dWlkKHVpZCk7DQogICAgICAgIGlmIChwd2QgPT0g TlVMTCkgew0KICAgICAgICAgICAgcGVycm9yKCJnZXRwd3VpZCIpOw0KICAgICAgICAgICAgZXhp dChFWElUX0ZBSUxVUkUpOw0KICAgICAgICB9DQogICAgICAgIGdpZCA9IHB3ZC0+cHdfZ2lkOw0K ICAgIH0NCg0KICAgIC8vINCf0YDQtdC+0LHRgNCw0LfRg9C10Lwg0L/RgNCw0LLQsCDQtNC+0YHR gtGD0L/QsCDQuNC3INGB0YLRgNC+0LrQuCAo0L3QsNC/0YDQuNC80LXRgCwgIjA3NTUiKQ0KICAg IG1vZGVfdCBtb2RlID0gc3RydG9sKGFyZ3ZbM10sICZlbmRwdHIsIDgpOw0KICAgIGlmICgqZW5k cHRyICE9ICdcMCcpIHsNCiAgICAgICAgZnByaW50ZihzdGRlcnIsICJJbnZhbGlkIG1vZGU6ICVz XG4iLCBhcmd2WzNdKTsNCiAgICAgICAgZXhpdChFWElUX0ZBSUxVUkUpOw0KICAgIH0NCg0KICAg IC8vINCc0LXQvdGP0LXQvCDQv9GA0LDQstCwINC00L7RgdGC0YPQv9CwDQogICAgaWYgKGZjaG1v ZGF0KEFUX0ZEQ1dELCBhcmd2WzJdLCBtb2RlLCBBVF9TWU1MSU5LX05PRk9MTE9XKSAhPSAwKSB7 DQogICAgICAgIHBlcnJvcigiZmNobW9kYXQiKTsNCiAgICAgICAgZXhpdChFWElUX0ZBSUxVUkUp Ow0KICAgIH0NCg0KICAgIC8vINCc0LXQvdGP0LXQvCDQstC70LDQtNC10LvRjNGG0LAg0Lgg0LPR gNGD0L/Qv9GDDQogICAgaWYgKGZjaG93bmF0KEFUX0ZEQ1dELCBhcmd2WzJdLCB1aWQsIGdpZCwg QVRfU1lNTElOS19OT0ZPTExPVykgIT0gMCkgew0KICAgICAgICBwZXJyb3IoImZjaG93bmF0Iik7 DQogICAgICAgIGV4aXQoRVhJVF9GQUlMVVJFKTsNCiAgICB9DQoNCiAgICBwcmludGYoIkNoYW5n ZWQgb3duZXJzaGlwIGFuZCBtb2RlIHN1Y2Nlc3NmdWxseS5cbiIpOw0KICAgIGV4aXQoRVhJVF9T VUNDRVNTKTsNCn0NCg==