* Quanah Gibson-Mount <[EMAIL PROTECTED]> [20050323 17:24]:
>
>
> --On Wednesday, March 23, 2005 2:50 PM -0800 Ben Poliakoff <[EMAIL
> PROTECTED]>
> wrote:
>
> >[ Hope this isn't too off topic for this list... ]
> >
> >At long last the most recent versions of Authen::SASL::Cyrus seem
> >to work properly (allowing me to write scripts that do GSSAPI
> >authenticated binds when connecting to an LDAP server).
> >
> >But I'm having a bit of trouble in trying to get Authen::SASL::Cyrus to
> >work *usefully* with GSSAPI while running under mod_perl.
> >
> >The problem is that when mod_perl compiles the script (as the apache
> >user) it calls out to libsasl and libgssapi_krb5 (et al) and consquently
> >embeds the credential cache location, specified in $ENV{KRB5CCNAME}, in
> >the compiled script.
> >
> >In other words the compiled script always looks for the kerberos
> >credential cache in the apache user's $ENV{KRB5CCNAME}. This would be
> >OK if my web application wasn't trying to authenticate to LDAP using
> >credentials *other* than those in the apache user's $ENV{KRB5CCNAME}.
> >
> >I'm using a web single signon system (umich's cosign) that can retrieve
> >a kerberos ticket for a user. As far as I can tell there isn't a way to
> >specify a credential cache with Authen::SASL::Cyrus (or is there?).
> >
> >Has anyone had some experience with this sort of issue?
>
> So you are saying essentially, that you want your application to ignore the
> Kerberos *standard* and do something non-compliant. I don't find that to
> be a particularly wise assumption to behave upon, myself.
I guess in my attempt at brevity I left out some details. I'm perfectly
happy with the krb5 libraries' use of KRB5CCNAME. The single sign on
system that I'm using populates $ENV{KRB5CCNAME} with the location of
the ticket of the authenticated user.
Perl scripts that run under mod_cgi work fine since they spawn a process
and inherit $ENV{KRB5CCNAME}. But when running under *mod_perl* the
script is compiled using apache user's environment, so it's stuck looking in
the default location for the apache user's ccache.
I was wondering whether anyone on this list has encountered this sort
of problem before, and knew of a way to get a script to reevaluate or
reset a variable that had been inherited at compile time. This issue
is, admittedly, not explicitly tied to perl-ldap. But I thought that it
might be a common enough issue for people working with perl-ldap that
the members of this list might have some helpful insights.
best wishes,
Ben
