su動作がPAM設定で提案されているものと異なる理由は確認できません。簡単に言えば、su別のユーザーになると、PAM構成に基づいてセカンダリグループをロードする必要がありますが、グループを追加せずにpam_groupLDAP/etc/security/group.confグループのみを残します。 SSH経由でユーザーとしてログインすると、2つのソースのグループがあります。
私たちの設定は、基本的な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いる2つのファイルは同じです）。system-authpassword-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
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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 - usernameroot（または他の人）と他のユーザーとして実行すると、sudo su - ...このpam_groupはこれらの追加グループを追加しないようです。実際にrootとしてログインすると、これらのグループが提供されます（pam_groupがそのタスクを実行したため）。実行すると、su - usernameこれらのグループが失われます。最初から始めるとPAMから取得したグループ（デフォルトではLDAPグループ、pam_groupはsu機能しません）
ここで、最初にrootとしてログインしたときにapache（48）、devs（501）、およびrvm（504）がありましたが、rootsu -として実行すると、root（0）コンテンツを除くすべてのコンテンツが失われたことがわかります。また、ユーザー「bob」としてログインすると、su - bobLDAPのグループはたくさんありますが（うまく機能する/ 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
最後にbobでSSHログインはどうなりますか？また、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
SSHログインとSSHを使用したログインの違いは、su - usernameSSHの場合に使用されるさまざまなモジュールにパスワードtry_first_passなどがありますが、Kerberosログインを頻繁に使用するため、これらのモジュールにはパスワードがないことが考えられます。
これらの矛盾を診断するのに役立つ場合は、合理的な範囲内で追加情報を提供します。よろしくお願いします！
編集する：
PAMデバッグがオンになっているがpam_groupトリガーされていないようですsu。無効にしてもpam_rootokログインする必要があります（実際に残りのpamスタックを通過しようとしていることを確認するため）。スタックのどこにあっても他の項目が実行されます（一度pam_rootok無効にすると、「十分な」状態がスタックを短絡しているように見えるため）。
ちょうどテストしてみようと思いましたが、sudoほぼ同じ問題があるようです。ルートはsudo自分のグループを保持できますが、sudo他のユーザーへのアクセスはLDAPグループのみを取得できます。同じスタックを/etc/pam.d/sudo使用することも含まれているので、これは驚くべきことではありません。ターゲットユーザーが現在のユーザーと同じである場合、実際には権限を削除したりユーザーを切り替えたりしないことが賢明であるため、ルートはグループを維持します。/etc/pam.d/system-authsusudo
ベストアンサー1
pam_rootokあなたの問題はsu-pamファイルとモジュールにあると仮定します。
#%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は、グループモジュールを次の場合にのみ機能させるのですか？承認する。実はそうしなければならないアカウント。