| Revision 24465,
845 bytes
checked in by broder, 15 years ago
(diff) |
|
Add a detailed note about why pam-afs-session isn't being used as an auth module.
|
| Rev | Line | |
|---|
| [24465] | 1 | pam_afs_session exports an auth interface to make sure it gets run |
|---|
| 2 | when PAM users call pam_setcred instead of |
|---|
| 3 | pam_open_session. Screensavers, for instance, do this. |
|---|
| 4 | |
|---|
| 5 | debathena-pam-config, however, does not configure pam_afs_session's |
|---|
| 6 | auth component. |
|---|
| 7 | |
|---|
| 8 | Because sudo's PAM configuration only includes /etc/pam.d/common-auth |
|---|
| 9 | and not /etc/pam.d/common-session, configuring pam_afs_session as an |
|---|
| 10 | auth module caused it to run under sudo when previously |
|---|
| 11 | pam_athena_locker did not. |
|---|
| 12 | |
|---|
| 13 | Configuring the auth module, combined with the fact that sudo doesn't |
|---|
| 14 | seem to set PAM's environment correctly, would cause pam_afs_session |
|---|
| 15 | to get run when sudo executed its PAM stack, create a new PAG, but |
|---|
| 16 | fail to get tokens (because KRB5CCNAME isn't set). |
|---|
| 17 | |
|---|
| 18 | Since part of the debathena-cluster login process is run through sudo, |
|---|
| 19 | this would cause users to not get tokens. |
|---|
Note: See
TracBrowser
for help on using the repository browser.
