Вопрос или проблема
У меня проблемы с определением того, почему su
не ведет себя так, как должна предполагать конфигурация PAM. Кратко говоря, использование su
для смены пользователя должно загружать вторичные группы в соответствии с конфигурацией PAM, но pam_group
не добавляет группы из /etc/security/group.conf
, в итоге мы получаем только наши группы LDAP. При входе по SSH как пользователь у вас есть группы из обоих источников.
Наша настройка не сильно отличается от стандартной CentOS 6.5, мы используем SSSD для входов через Kerberos / LDAP, но, если я правильно помню, не вносили прямые изменения в что-либо в /etc/pam.d
, изменения были сделаны с помощью:
authconfig --updateall --enablesssd --enablesssdauth --enablemkhomedir
Существует, конечно, отдельные файлы /etc/pam.d/su
и /etc/pam.d/sshd
, но оба включают идентичные файлы, в которых вызывается pam_group.so
(включая system-auth
и password-auth
соответственно, но эти два включенных файла идентичны).
Соответствующий раздел /etc/pam.d/su
:
#%PAM-1.0
auth sufficient pam_rootok.so
auth include system-auth
Соответствующий раздел /etc/pam.d/sshd
:
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
В включенном файле:
#%PAM-1.0
# Этот файл сгенерирован автоматически.
# Изменения пользователей будут уничтожены при следующем запуске authconfig.
auth required pam_env.so
auth optional pam_group.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
...
При входе по SSH строка pam_group.so добавляет группы через /etc/security/group.conf
, добавляя группу ‘apache’ (среди прочих) для всех, кто входит:
*;*;*;Al0000-2400;apache,devs,rvm
При выполнении su - username
от имени root (или sudo su - ...
от имени любого другого пользователя) и переходе к другому пользователю, этот pam_group, похоже, не добавляет дополнительные группы. На самом деле, при входе как root вы получаете эти группы (потому что pam_group выполняет свою работу), а запуск su - username
приводит к потере этих групп, потому что su
начинает с нуля и добавляет только группы, которые получает от PAM (в основном группы LDAP, поскольку pam_group не работает)
Здесь вы можете видеть, что, войдя изначально как root, я имею apache (48), devs (501) и rvm (504), но при выполнении просто su -
для входа как root я теряю все, кроме root (0). Кроме того, входя как пользователь ‘bob’ с помощью su - bob
, вы можете видеть, что у меня много групп из LDAP (плюс одна жестко закодированная группа из /etc/group, которая работает), но ничего из /etc/security/group.conf
.
[root@dev-web pam.d]# id -G
0 48 501 504
[root@dev-web pam.d]# su -
[root@dev-web ~]# id -G
0
[root@dev-web ~]# logout
[root@dev-web pam.d]# su - bob
[bob@dev-web ~]$ id -G
1005001 10 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034
Наконец, вот как выглядит вход по SSH как bob – опять же, у меня есть apache (48), devs (501) и rvm (504).
[bob@dev-web ~]$ id -G
1005001 10 48 501 504 1001000 1001001 1001002 1001003 1001004 1001005 1001008 1001009 1001010 1001011 1001012 1001017 1001018 1001025 1001027 1001028 1001033 1001034
Можно предположить, что разница между su - username
и входом по SSH заключается в том, что в случае SSH есть пароль, доступный для различных модулей, использующих try_first_pass
и так далее, но, поскольку мы часто входим с помощью Kerberos, у этих модулей нет пароля.
Я предоставлю любую дополнительную информацию (в разумных пределах), если это поможет диагностировать это несоответствие. Спасибо заранее!
Редактировать:
Я включил отладку PAM, и pam_group
, похоже, не срабатывает для su
– даже если я отключаю pam_rootok
, чтобы мне пришлось войти (чтобы убедиться, что он действительно пытался пройти через остальную часть стека pam). Независимо от того, где он находится в стеке, другие элементы срабатывают (как только pam_rootok
отключено, так как его статус “sufficient” кажется, сокращает стек).
Также мне только сейчас стало интересно протестировать sudo
, и, похоже, у него практически такая же проблема. Root может sudo
к самому себе и сохранить группы, но при sudo
к другому пользователю мы получаем только группы LDAP. /etc/pam.d/sudo
просто включает /etc/pam.d/system-auth
, который использует тот же стек, что и su
, так что это не должно быть сюрпризом. Я полагаю, sudo
достаточно умен, чтобы не сбрасывать полномочия / менять пользователя, если целевой пользователь такой же, как текущий пользователь, отсюда и сохранение групп root.
Я предполагал, что ваша проблема связана с файлом pam su и модулем pam_rootok
.
#%PAM-1.0
auth sufficient pam_rootok.so
auth include system-auth
Клаузула sufficient
сокращает процесс аутентификации. Таким образом, system-auth никогда не включается, что означает, что модуль pam_group никогда не активируется для этой сессии.
Затем, вздыхая, я прочитал ваше редактирование. Тем не менее, это определенно начало в поисках решения этой проблемы. Возможно, включите отладку для pam_group, чтобы увидеть, возвращает ли он одно из задокументированных значений ошибки (man pam_group
).
Что касается sudo, то это действительно имеет смысл, что после аутентификации пользователя через PAM, вся информация о учетной записи выбрасывается/отключается. У него есть свои механизмы для добавления пользователей в группы. Попробуйте добавить параметр preserve_groups
для соответствующей записи sudo.
Все это заставляет меня задуматься: почему pam сделал модуль группы только актуальным для auth. На самом деле, он должен быть частью account.
Строки auth рассматриваются только при обработке пароля, поэтому они игнорируются для su, когда вы root, или для ssh с использованием открытого ключа.
Мне не удалось найти способ заставить это работать.
У меня такая же проблема, и я нашел решение, добавив выделенную строку:
auth required pam_group.so
Теперь это выглядит так:
cat /etc/pam.d/su | grep -v '^\s*$\|^\s*\#'
auth required pam_group.so
auth sufficient pam_rootok.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
session optional pam_mail.so nopen
session required pam_limits.so
@include common-auth
@include common-account
@include common-session
Ответ или решение
Когда вы пытаетесь использовать команду su - username
, а также сталкиваетесь с проблемами в организации групп пользователей, стоит обратить внимание на настройки PAM (Pluggable Authentication Modules) и поведение модулей аутентификации. В вашем случае pam_group
не добавляет дополнительные группы из /etc/security/group.conf
, в то время как авторизация через SSH работает корректно. Давайте проанализируем вашу конфигурацию более подробно.
Основные моменты конфигурации
Вы упомянули, что используете стандартные настройки на CentOS 6.5 с включенной поддержкой SSSD для Kerberos/LDAP. По умолчанию конфигурация PAM довольно обширна и требует внимания к каждой детали.
Вот структура вашего /etc/pam.d/su
файла:
#%PAM-1.0
auth sufficient pam_rootok.so
auth include system-auth
И /etc/pam.d/sshd
:
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
Содержимое включенных файлов (например, system-auth
) выглядит следующим образом:
# This file is auto-generated.
auth required pam_env.so
auth optional pam_group.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
...
Проблема с настройкой PAM
Как вы уже отметили, проблема заключается в том, что при использовании su
модуль pam_group.so
не активируется должным образом, что приводит к потере групп. Это может быть связано с тем, что строка auth sufficient pam_rootok.so
фактически прерывает выполнение остальной части PAM стека, когда пользователь является root. В этом случае, далее не выполняется pam_group
, что может объяснить отсутствие дополнительных групп, в том числе и тех, что указаны в /etc/security/group.conf
.
Чтобы решить эту проблему, я рекомендую изменить порядок выполнения модулей. Добавьте строку auth required pam_group.so
перед auth sufficient pam_rootok.so
, чтобы гарантировать, что PAM все еще проверяет pam_group
перед тем, как сработает механика прерывания:
#%PAM-1.0
auth required pam_group.so
auth sufficient pam_rootok.so
auth include system-auth
Поведение команды sudo
С командой sudo
может возникнуть аналогичная ситуация, так как он также использует тот же стек PAM. Вы правы, что поведение sudo
иногда предотвращает потерю групп, когда вы пытаетесь выполнить команду для того же пользователя. Для исправления ситуации с sudo
, вы можете рассмотреть возможность использования параметра preserve_groups
, который позволит сохранять группы при смене пользователя.
Заключение
Проблема с конфигурацией PAM в данной ситуации довольно распространена и связана с порядком модулей и их влиянием на пересечение групп. Чтобы обеспечить правильную работу pam_group
, важно корректно наладить порядок его выполнения в конфигурационных файлах PAM. После внесения изменений в /etc/pam.d/su
, протестируйте снова и проверьте, сохраняются ли группы пользователей, как ожидается.
Не стесняйтесь задавать дополнительные вопросы о своей конфигурации или проблемах, с которыми вы сталкиваетесь. Надеюсь, данная информация окажется полезной!