[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Server-side Cyrus SASL support

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-09-15 17:12:56 CEST

On 9/15/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> On 9/6/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 9/1/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> > > On 8/29/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > > > On 8/29/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> > > >
> > > > > Ouch. I don't know if it's related to the crash or not, but I noticed
> > > > > I forgot to do any error-checking when calling sasl_init() in main. So
> > > > > SASL might not have been initialized.
> > > >
> > > > That could certainly be an issue.
> > >
> > > I figured out why your initialization failed. Turns out that once we
> > > added those if statements to the mutex callbacks they could no longer
> > > be used by the server because the server doesn't initialize
> > > sasl_status (The reason it worked for me when testing those changes is
> > > that I didn't bother to restart the server after recompiling). So I
> > > made sasl_status public (see the log message) and changed svnserve's
> > > sasl_init() to call svn_atomic_init_once().
> > >
> > > I also fixed a client-side bug where the value of the 'creds' variable
> > > wasn't checked as early as it should have been (see the second log
> > > message).
> >
> > For what it's worth, I've tried this, and it does indeed stop the
> > crashing, but I can't seem to get it to actually work. More debugging
> > later, as I'm still not sure I haven't just screwed something up in my
> > sasl configuration...
> >
> > -garrett
> >
>
> Hi,
>
> I attached a new version of my patch, with a couple of minor fixes.
>
> Also, before testing this, please apply the client-side fix that I
> mentioned in my previous e-mail. Without it the client will lose the
> last error message returned by the server (this happens because
> last_err is allocated in a subpool, so we have to use it before
> restarting the enclosing loop, which clears the pool). With that fix
> in place, if the authentication still fails, you should at least get a
> decent error message.

Ahh, good to know, I'll take a look at this later today.

Thanks!

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 15 17:13:11 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.