Не отображаются группы пользователя по id или groups

[vvschaos]

Здравствуйте все!
У меня проблема.
Есть сервер с CentOS 5. Установлен LDAP, есть LDAP аутентификация нескольких приложений (типа svn, wiki)... В системе, когда добавляю юзера в группу всё нормально проходит (gpasswd -a user group), он появляется в /etc/groups, но когда я выбираю id user или groups для этого юзера, то он не показывает все группы к которым он принадлежит, только собственную. Естесственно, если поменять свойства директории на чтение и запись для группы в которую он входит, то ничего не получается сделать. В чём может быть проблема? Может она простая, но я что-то не соображу что делать

[Ariasp]

он появляется в /etc/groups, но когда я выбираю id user или groups для этого юзера, то он не показывает все группы к которым он принадлежит, только собственную.

наводящий вопрос -- есть ли группы, к которым он "должен" принадлежать, в выводе команды getent group

[vvschaos]

он появляется в /etc/groups, но когда я выбираю id user или groups для этого юзера, то он не показывает все группы к которым он принадлежит, только собственную.

наводящий вопрос -- есть ли группы, к которым он "должен" принадлежать, в выводе команды getent group

есть

[Ariasp]

есть

тогда в этом же выводе перечислены и все member-ы групп; если юзер не перечислен в группе, то естественно и id с groups не будут отображать эту группу

[vvschaos]

есть

тогда в этом же выводе перечислены и все member-ы групп; если юзер не перечислен в группе, то естественно и id с groups не будут отображать эту группу

он перечислен в группе, в этом то всё и дело

[nesk]

а что в файле /etc/nsswitch написано в поле group: и passwd: ?

ЗЫ Важно! После добавления пользователя в группу, пользователь должен перелогиниться (перезайти в систему заново) !!

[vvschaos]

а что в файле /etc/nsswitch написано в поле group: и passwd: ?

ЗЫ Важно! После добавления пользователя в группу, пользователь должен перелогиниться (перезайти в систему заново) !!

/etc/nsswitch.conf

passwd: files [!NOTFOUND=return] ldap
shadow: files
group: files [!NOTFOUND=return] ldap

перелогинивался - результат тот же

[Ariasp]

passwd: files [!NOTFOUND=return] ldap
shadow: files
group: files [!NOTFOUND=return] ldap

А с какой целью переопределено дефолтное поведение nss, да ещё так своеобразно - [!NOTFOUND=return] (ладно бы [NOTFOUND=return], так ещё и добавлено отрицание)? Фактически сейчас для nss указано, что если учётка найдена в posix-таблицах /etc/passwd и /etc/groups, то просмотр базы ldap вести не нужно. Пожалуй этим и объясняется странное поведение id и groups.
Подозреваю, что указанное переопределение было сделано из-за проблем с длительной загрузкой. Если это так, то бороться с этой проблемой следует иначе.
Вобщем можно попробовать вернуть дефолтное поведение хотя бы для групп:
passwd: files [!NOTFOUND=return] ldap
shadow: files
group: files ldap
после залогиниться в другой сессии и посмотреть, как изменился вывод id

[vvschaos]

passwd: files [!NOTFOUND=return] ldap
shadow: files
group: files [!NOTFOUND=return] ldap

А с какой целью переопределено дефолтное поведение nss, да ещё так своеобразно - [!NOTFOUND=return] (ладно бы [NOTFOUND=return], так ещё и добавлено отрицание)? Фактически сейчас для nss указано, что если учётка найдена в posix-таблицах /etc/passwd и /etc/groups, то просмотр базы ldap вести не нужно. Пожалуй этим и объясняется странное поведение id и groups.
Подозреваю, что указанное переопределение было сделано из-за проблем с длительной загрузкой. Если это так, то бороться с этой проблемой следует иначе.
Вобщем можно попробовать вернуть дефолтное поведение хотя бы для групп:
passwd: files [!NOTFOUND=return] ldap
shadow: files
group: files ldap
после залогиниться в другой сессии и посмотреть, как изменился вывод id

было в начале [NOTFOUND=return], после этого наступила жопа, к серверу вообще невозможно было подлогиниться, пришлось перегружаться с указанием init=/bin/bash... Поэтому учётка так и сделана, что если найден пользователь в /etc/passwd и /etc/group, то просматривать ldap НЕ нужно.
Если указано просто group files ldap, то начинаются очень сильные бока, если вдруг openldap падает или останавливается.

[Ariasp]

было в начале [NOTFOUND=return], после этого наступила жопа, к серверу вообще невозможно было подлогиниться, пришлось перегружаться с указанием init=/bin/bash... Поэтому учётка так и сделана, что если найден пользователь в /etc/passwd и /etc/group, то просматривать ldap НЕ нужно.

чем тогда не устраивает [SUCCESS=return]; [!NOTFOUND=return] смотрится своеобразно -- "не не найден"

Если указано просто group files ldap, то начинаются очень сильные бока, если вдруг openldap падает или останавливается.

для этого в конфиге ldap-клиента nss есть параметр nss_initgroups_ignoreusers; чтобы не было указанных проблем, в нём нужно перечислить все учётки, под которыми запущены демоны на этом сервере; например
nss_initgroups_ignoreusers root,ldap,apache,mysql,named

[vvschaos]

было в начале [NOTFOUND=return], после этого наступила жопа, к серверу вообще невозможно было подлогиниться, пришлось перегружаться с указанием init=/bin/bash... Поэтому учётка так и сделана, что если найден пользователь в /etc/passwd и /etc/group, то просматривать ldap НЕ нужно.

чем тогда не устраивает [SUCCESS=return]; [!NOTFOUND=return] смотрится своеобразно -- "не не найден"

Если указано просто group files ldap, то начинаются очень сильные бока, если вдруг openldap падает или останавливается.

для этого в конфиге ldap-клиента nss есть параметр nss_initgroups_ignoreusers; чтобы не было указанных проблем, в нём нужно перечислить все учётки, под которыми запущены демоны на этом сервере; например
nss_initgroups_ignoreusers root,ldap,apache,mysql,named

Надо будет попробовать [SUCCESS=return], хотя [!NOTFOUND=return] меня сейчас вполне устраивает казалось логичнее как раз что если не найден, тем более, что на другом сервере с такими параметрами нормально всё отображается...
Проблема всё равно не в этом, группы локальных юзеров не показываются по id .

Попробовал прописать в nss_init_group_ignoreusers этого созданного юзера, перезапустил ldap, но по id показывает всё равно упорно только его собственную группу

[nesk]

а что у Вас /etc/pam.d/system-auth ?

[Ariasp]

Попробовал прописать в nss_init_group_ignoreusers этого созданного юзера, перезапустил ldap, но по id показывает всё равно упорно только его собственную группу

ещё раз -- nss_init_group_ignoreusers из /etc/ldap.conf нужна для того, чтобы демоны на серваке не пытались коннектиться к ldap-серверу -- это нужно для того, чтобы не было "боков" в случае, если ldap-сервер упадёт либо при старте (пока ldap-сервер не стартовал); эта настройка не связана с отображением групп в команде id

тем более, что на другом сервере с такими параметрами нормально всё отображается...
Проблема всё равно не в этом, группы локальных юзеров не показываются по id

странно это; воспроизвёл ситуацию на одной из своих тачек; в nsswitch.conf
group: files [SUCESS=return] ldap
-- как ожидалось, группы из ldap на id перестали отображаться; но при этом и на getent group они перестали отображаться; вернул group: files ldap -- всё вернулось к нормальному отображению
твоя ситуация воспроизводится только в случае, когда в /etc/ldap.conf раскомментирована директива nss_initgroups backlink ; соответственно вопрос - оно тебе реально надо или это результат творческих мучений по избавлению от "боков" при падении ldap-сервера?

[vvschaos]

а что у Вас /etc/pam.d/system-auth ?

auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so

Попробовал прописать в nss_init_group_ignoreusers этого созданного юзера, перезапустил ldap, но по id показывает всё равно упорно только его собственную группу

ещё раз -- nss_init_group_ignoreusers из /etc/ldap.conf нужна для того, чтобы демоны на серваке не пытались коннектиться к ldap-серверу -- это нужно для того, чтобы не было "боков" в случае, если ldap-сервер упадёт либо при старте (пока ldap-сервер не стартовал); эта настройка не связана с отображением групп в команде id

тем более, что на другом сервере с такими параметрами нормально всё отображается...
Проблема всё равно не в этом, группы локальных юзеров не показываются по id

странно это; воспроизвёл ситуацию на одной из своих тачек; в nsswitch.conf
group: files [SUCESS=return] ldap
-- как ожидалось, группы из ldap на id перестали отображаться; но при этом и на getent group они перестали отображаться; вернул group: files ldap -- всё вернулось к нормальному отображению
твоя ситуация воспроизводится только в случае, когда в /etc/ldap.conf раскомментирована директива nss_initgroups backlink ; соответственно вопрос - оно тебе реально надо или это результат творческих мучений по избавлению от "боков" при падении ldap-сервера?

Это скорее результат "творческих мучений"... Когда было files ldap и очень неожиданно упал openldap на живом сервере который находится территориально очень далеко, то наступила полная жопа... Просто перестал заходить через ssh, причём даже root'ом не мог подконнектиться, хотя в /etc/ldap.conf есть запись nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon и т.д... Спасло только iLO...

[nesk]

хм. странно

давайте до кучи
grep <user_name> /etc/passwd
grep <user_name> /etc/group
getent passwd <user_name>
getent group <group_name>

[vvschaos]

хм. странно

давайте до кучи
grep <user_name> /etc/passwd
grep <user_name> /etc/group
getent passwd <user_name>
getent group <group_name>

ok

grep user /etc/passwd
user:x:501:501::/home/user:/bin/bash

grep user /etc/group
wheel:x:10:root,user
user::501:
svn:x:1026:user
ftp_users:!:1003:user

getent passwd user
user:x:501:501::/home/user:/bin/bash

getent group user
user::501:

при этом id user:
uid=501(user) gid=501(user) groups=501(user)

[nesk]

угу
а что будет если user сделает
newgrp wheel
?
а потом посмотреть id


и еще, я бы хотел увидеть
getent group wheel
getent group svn
скорее всего ничего интересного и отличного от того что мы видели, не будет, но всё таки.. так сказать до кучи

[vvschaos]

угу
а что будет если user сделает
newgrp wheel
?
а потом посмотреть id


и еще, я бы хотел увидеть
getent group wheel
getent group svn
скорее всего ничего интересного и отличного от того что мы видели, не будет, но всё таки.. так сказать до кучи

Если сделать newgr ftp_users, то по id выводится группа, но делаешь exit и всё... Группы опять нет...

по командам - ничего нового:
getent group whee
wheel:x:10:root,user

getent group svn
svn:x:1026:user

[nesk]

Если сделать newgr ftp_users, то по id выводится группа, но делаешь exit и всё... Группы опять нет...

очень хорошо
значит так и должно быть.
значит такова особенность привилегированных групп в юникс системах, что пока в неё явно не переключишься, ты в ней не числишься.
если хотите по другому, то используйте обычные группы без паролей.
(usrrmod -Ga ftp_users user)

[vvschaos]

Если сделать newgr ftp_users, то по id выводится группа, но делаешь exit и всё... Группы опять нет...

очень хорошо
значит так и должно быть.
значит такова особенность привилегированных групп в юникс системах, что пока в неё явно не переключишься, ты в ней не числишься.
если хотите по другому, то используйте обычные группы без паролей.
(usrrmod -Ga ftp_users user)

не совсем понял как мне может помочь? да я добавляю к одной группе, но почему то что описано в /etc/group всё равно игнорируется?

[Ariasp]

не совсем понял как мне может помочь? да я добавляю к одной группе, но почему то что описано в /etc/group всё равно игнорируется?

Так я не понял, у тебя nss_initgroups backlink в /etc/ldap.conf закомментирован или нет? К чему упражняться с getent и id - это тебе точно не поможет.

[vvschaos]

не совсем понял как мне может помочь? да я добавляю к одной группе, но почему то что описано в /etc/group всё равно игнорируется?

Так я не понял, у тебя nss_initgroups backlink в /etc/ldap.conf закомментирован или нет? К чему упражняться с getent и id - это тебе точно не поможет.

хм.. у меня совсем нет такой записи в /etc/ldap.conf

[nesk]

не совсем понял как мне может помочь? да я добавляю к одной группе, но почему то что описано в /etc/group всё равно игнорируется?

оно не игнорируется. просто Вы используете привилегированные группы, а в них надо каждый раз явно переключаться.
не используйте привилегированный группы и тогда права всех групп будут применяться кумулятивное.

Кажется

[sash-kan]

беглый просмотр исходников пакета coreutils (куда входит программа /usr/bin/id) наводит на мысли, связанные с реализацией библитотечной функции getgroups.
возможно, на ее работу оказывает влияние selinux, включенный в centos по умолчанию (afaik). или ldap.
хотя, конечно, моих познаний недостаточно для того, чтобы предположить — _в_чем_ может заключаться это влияние.

p.s. кстати, прямой запрос всех групп:
$ id -Gn
может быть на какие-то мысли вас наведет даже простое прохождение trace-ом по вызову этой команды.
$ strace id -G
(лучше без -n, для простоты).

[sash-kan]

2 nesk гхм. а что это за «привилегированные группы»? что вы под ними подразумеваете? честное слово, первый раз слышу такой термин.

[Ariasp]

у меня совсем нет такой записи в /etc/ldap.conf

запости тогда сюда его содержимое

[Ariasp]

2 nesk гхм. а что это за «привилегированные группы»? что вы под ними подразумеваете? честное слово, первый раз слышу такой термин.

да тут всё понятно - он считает группу wheel "привилегированной"; и на основании неадекватного поведения оси из этого топика делает вывод, что везде в линукс в неё "надо каждый раз явно переключаться"

[nesk]

2 nesk гхм. а что это за «привилегированные группы»? что вы под ними подразумеваете? честное слово, первый раз слышу такой термин.

те группы для переключение в которые надо вводить пароль. может термин и не правильный
короче группа, что бы стать членом которой надо явно выполнить newgrp
ну может я и не прав и такого не существует вообще

sash-kan это нормально, что vvschaos для управления членством пользователей в группе использовал команду gpasswd, а не usermod?
посмотрел сейчас в инете man gpasswd... много думал

[Ленивая Бестолочь]

http://heap.altlinux.org/modules/users_in_...ill/index.html:

Иногда в файле /etc/group заполняется поле password (пароль) для того, чтобы установить пароль на групповой доступ. Это требуется редко. Для того, чтобы не позволять пользователям проникать в привилегированные группы (командой newgroup), в это поле надо поставить символ *.

мне вот в этом плане всегда было интересно как такие группы администрировать в LDAP.
поле пароль я там добавить могу, а как, например, назначить администраторов группы? таких полей в стандартной схеме не видно.

....наверное все таки функции администратора групп должны даваться через slapd.conf - где в конце написаны acl-и...

[sash-kan]

sash-kan это нормально, что vvschaos для управления членством пользователей в группе использовал команду gpasswd, а не usermod?
посмотрел сейчас в инете man gpasswd... много думал

эге. слона-то я и не заметил. как-то пропустил мимо ушей упоминание gpasswd.
если группам присвоены пароли, тогда становится понятным отсутствие их в выводе id.

p.s. 2 vvschaos: ещё есть такая программка, как sg (аналог su, но в контексте групп).

p.p.s. с трудом представляю себе ситуацию, в которой понадобились бы пароли к группам.