On Fri, Aug 26, 2011 at 12:57:50PM -0700, Steve Langasek wrote: > On Fri, Aug 26, 2011 at 01:41:34PM -0600, Bdale Garbee wrote: > > On Fri, 26 Aug 2011 20:25:31 +0200, Michael Schuerig <mich...@schuerig.de> > > wrote: > > > The changed > > > PAM configuration has the effect that at the start of a sudo > > > session the ecryptfs mount count is *not* incremented, while it > > > is decremented when the session ends.
> > I'm not enough of a pam expert to know immediately how to resolve this. > > Any suggestions? Steve? > What change to the PAM configuration is referred to here? Ah, I see, common-session is now included - that's good. :) But if the calls to pam_open_session() and pam_close_session() are not symmetric in sudo, that's bad. It's actually quite surprising that this should happen, as it's much more common for services to get the open_session() right and miss the close_session(). In fact, this is exactly what I see in the case of sudo with cached credentials: pam_open_session() is called, pam_close_session() is not. (That's also a bug - but not the one causing the problem Michael sees.) Looking closely, I see that pam_open_session() is called with PAM_USER=<target user>, and pam_close_session() is called with PAM_USER=<source user>. That's definitely wrong, the value should be the same for both calls. The mismatch probably has to do with sudo's peculiarity of using authentication credentials of the source user to authorize access to a different target user, instead of using credentials for the target user. I think this needs to be looked at by sudo upstream. (Debugged using 'session optional pam_warn.so' added to /etc/pam.d/sudo, btw - logs useful information about what pam's thinking to /var/log/auth.log.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
