----- Original Message -----
> From: "Petr Vobornik" <pvobo...@redhat.com>
> To: "Simo Sorce" <s...@redhat.com>
> Cc: "freeipa-devel" <firstname.lastname@example.org>
> Sent: Wednesday, March 16, 2016 12:16:02 PM
> Subject: Re: [PATCH] 955 sessions: use unique mod_auth_gssapi ccaches
> On 03/10/2016 03:25 PM, Simo Sorce wrote:
> > On Thu, 2016-03-10 at 15:03 +0100, Petr Vobornik wrote:
> >> Attaching also mod_auth_gssapi patch. If the approach is good, then I'd
> >> send it as a push request to upstream git repo.
> >> Copr build of mod_auth_gssapi with the patch:
> >> https://copr.fedorainfracloud.org/coprs/pvoborni/freeipa-4-3/build/167157/
> >> IPA patch attached uses the functionality.
> >> https://fedorahosted.org/freeipa/ticket/5653
> > I think the mod_auth_gssapi patch needs more work.
> New iteration, but not a final patch, mostly because of reaping of the
> files, but there are also some debug prints.
> > For one you are not storing the generated ccname in the cookie, which
> > means any following request using mod_auth_gssapi sessions will not be
> > able to point to the ccache file.
> Do you mean session? Cookie should contain only session ID, right?
No, in other to avoid having to keep state on the server we create a session
structure, encrypt it in a key known only to the server, and send it as a
This way we do not have to store anything on the server side.
> > It is also not clear to me why you are using a timestamp and not just
> > call something like mkstemp() with a template, and add an option called
> > GssapiDelegCcacheTemplate instead.
> I didn't think about that.
> > The templated part would have to be saved in the session so that
> > following requests can keep using the same ccache file.
> Fixed (but not tested yet)
> > There are other minor niticks around naming stuff, but those can be
> > handled in the PR.
> > One thing I am still undecided about is deletion of the files, I'd like
> > to have a better option than "application must delete them", I was
> > thinking about keeping a record of the expiration time (not sure where
> > yet), and then provide a cron job or a systemd timer to clean up all
> > expired stuff.
> I thought we won't need it and that it could be handled by apps, but
> that won't work.
> Case 1: ipa kerberize entire /ipa directory so a request to a random
> resource might leave a ccache behind, e.g.:
> curl -v --negotiate -u : --cacert /etc/ipa/ca.crt
> ls /var/run/httpd/ipa/clientcaches/
> Case 2: custodia, it doesn't clean anything as well.
> When sessions are not it play then, the plugin can remove the ccache at
> the end of request. AFAIK mod_auth_kerb does it.
> With sessions, there needs to be a reaper.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code