[92] in athena10
Re: PAM, schroot, and debathenificator
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Fri Feb 22 13:38:28 2008
Date: Fri, 22 Feb 2008 13:38:14 -0500 (EST)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: ghudson@mit.edu
cc: athena10@mit.edu
In-Reply-To: <200802220536.m1M5a1hK001697@outgoing.mit.edu>
Message-ID: <Pine.LNX.4.64L.0802221333320.17684@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
I wonder whether this PAM behavior is a bug in schroot. Unlike most
applications of PAM, here the PAM session modules are being run when
entering the chroot from the host machine, whereas normally they should be
run when logging into the machine. It certainly results in problems in
our case, and I'm not sure what utility it is providing... perhaps they
intended to run the PAM from inside the chroot?
I suspect an alternative workaround would be to cause schroot to pass the
KRB5CCNAME environment variable into the chroot, so that we get new
tokens on schroot.
-Tim Abbott
On Fri, 22 Feb 2008, ghudson@MIT.EDU wrote:
> debathenificator runs commands like:
>
> schroot -c "$chroot" -- apt-get -d source "$name"
>
> and expects apt-get to be able to write the results into the current
> AFS directory. Unfortunately, that does not work with current schroot
> in the default configuration, because it creates a PAM session which
> winds up invoking pam_athena_locker which creates a fresh pag with no
> tokens in it.
>
> The workaround is to edit /etc/pam.d/schroot, comment out:
>
> @include common-session
>
> and add:
>
> # Basic pam_unix session module in place of common-session.
> session required pam_unix.so
>
> If you don't add a dummy session module of some kind, it falls back to
> /etc/pam.d/other which winds up invoking pam_athena_locker anyway.
>
