AFS and Apache
Having sorted out mail on AFS, I moved on to Apache on AFS (or more appropriately, with access to AFS).
This ended up being a problem since Apache handles privileges different than Postfix and Dovecot. The way I had my PAM stack set up, pam_afs_session.so was getting AFS PAGs when I su'd, meaning that su'ing to the Apache user to k5start would get me nowhere since the AFS tokens I got would be associated with a PAG that the server itself would not be running as.
Once I got a good handle on how PAGs work, I got to work disabling them. Reason being that unless you authenticate through AFS directly instead of using your Kerberos credentials and the afs service ticket to get tokens, there's no security offered in using PAGs. The whole point of a PAG is so someone with root on an AFS client box can't su to a user and have access to their tokens. But Kerberos offers no such functionality with tickets, so if a user has tickets and I su to them, I can just aklog and get my own tokens as them. The only way I can see a user preventing a local superuser from getting tokens is to get both tickets and tokens, then destroy the tickets (so they have tokens but no tickets from which to get new tokens).
If I'm misunderstanding this and disabling PAGs has greater security implications, please let me know!
So back to work... I set the nopag option on pam_afs_session.so in /etc/pam.d/common-auth and /etc/pam.d/common-session. Now I wasn't getting PAGs (yay!), but IMAP broke (boo!).
So I copied the contents of /etc/pam.d/common-* to /etc/pam.d/dovecot, re-enabling PAG for dovecot by removing nopag (but leaving it in common-*).
So I would think that if dovecot needs PAGs in this manner, postfix/local would too. But it doesn't. And I'm not sure why. I have a couple guesses... like dovecot is spawning a separate imap process as you to hand you off to once you've authenticated, so that process needs the PAG, whereas local is all done in a single process. But then by that logic, procmail shouldn't work? Or, dovecot actually auth's you via PAM where local doesn't. That could be it...
My brain hurts, I'm going home.
This ended up being a problem since Apache handles privileges different than Postfix and Dovecot. The way I had my PAM stack set up, pam_afs_session.so was getting AFS PAGs when I su'd, meaning that su'ing to the Apache user to k5start would get me nowhere since the AFS tokens I got would be associated with a PAG that the server itself would not be running as.
Once I got a good handle on how PAGs work, I got to work disabling them. Reason being that unless you authenticate through AFS directly instead of using your Kerberos credentials and the afs service ticket to get tokens, there's no security offered in using PAGs. The whole point of a PAG is so someone with root on an AFS client box can't su to a user and have access to their tokens. But Kerberos offers no such functionality with tickets, so if a user has tickets and I su to them, I can just aklog and get my own tokens as them. The only way I can see a user preventing a local superuser from getting tokens is to get both tickets and tokens, then destroy the tickets (so they have tokens but no tickets from which to get new tokens).
If I'm misunderstanding this and disabling PAGs has greater security implications, please let me know!
So back to work... I set the nopag option on pam_afs_session.so in /etc/pam.d/common-auth and /etc/pam.d/common-session. Now I wasn't getting PAGs (yay!), but IMAP broke (boo!).
So I copied the contents of /etc/pam.d/common-* to /etc/pam.d/dovecot, re-enabling PAG for dovecot by removing nopag (but leaving it in common-*).
So I would think that if dovecot needs PAGs in this manner, postfix/local would too. But it doesn't. And I'm not sure why. I have a couple guesses... like dovecot is spawning a separate imap process as you to hand you off to once you've authenticated, so that process needs the PAG, whereas local is all done in a single process. But then by that logic, procmail shouldn't work? Or, dovecot actually auth's you via PAM where local doesn't. That could be it...
My brain hurts, I'm going home.
posted by nocones at 4:34 PM
0 Comments:
Post a Comment
<< Home