On 8/29/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> Ok, now that we're past the weird pool ordering bugs, I actually got
> to the point of trying out the SASL support. I think I've got it
> configured the way you suggested, but I'm getting the following crash
> when I try to run 'svn list' on a repository with sasl turned on.
>
> (gdb) run
> Starting program:
> /home/rooneg/code/svn-trunk/subversion/svnserve/.libs/lt-svnserve -d
> --foreground -r /home/rooneg/code/svn-trunk -T
> [Thread debugging using libthread_db enabled]
> [New Thread -1212417312 (LWP 13558)]
> [New Thread -1213510736 (LWP 13563)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1213510736 (LWP 13563)]
> 0xb7d5e817 in sasl_errdetail () from /usr/lib/libsasl2.so.2
> (gdb) where
> #0 0xb7d5e817 in sasl_errdetail () from /usr/lib/libsasl2.so.2
> #1 0x0804c775 in sasl_auth_request (conn=0x80716e8, pool=0x80713b8,
> b=0xb7ab43a0, required=READ_ACCESS, needs_username=0)
> at subversion/svnserve/sasl_auth.c:262
> #2 0x0804d2cb in auth_request (conn=0x80716e8, pool=0x80713b8, b=0xffffffff,
> required=READ_ACCESS, needs_username=0) at subversion/svnserve/serve.c:329
> #3 0x08051bf0 in serve (conn=0x80716e8, params=0xbfbb2518, pool=0x80713b8)
> at subversion/svnserve/serve.c:2284
> #4 0x0804b599 in serve_thread (tid=0x80737b8, data=0x8071270)
> at subversion/svnserve/main.c:253
> #5 0xb7e01992 in dummy_worker (opaque=0x0) at thread.c:105
> #6 0xb7d72341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
> #7 0xb7cf04ee in clone () from /lib/tls/i686/cmov/libc.so.6
> (gdb) up
> #1 0x0804c775 in sasl_auth_request (conn=0x80716e8, pool=0x80713b8,
> b=0xb7ab43a0, required=READ_ACCESS, needs_username=0)
> at subversion/svnserve/sasl_auth.c:262
> 262 return svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
> (gdb) list
> 257 secprops.security_flags |= SASL_SEC_NOANONYMOUS;
> 258
> 259 /* Set security properties. */
> 260 result = sasl_setprop(sasl_ctx, SASL_SEC_PROPS, &secprops);
> 261 if (result != SASL_OK)
> 262 return svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
> 263 sasl_errdetail(sasl_ctx));
> 264
> 265 /* SASL needs to know if we are externally authenticated. */
> 266 if (b->tunnel_user)
> (gdb)
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.
OTOH, it's probably not a good idea to initialize SASL in main anyway,
because it's a potentially expensive operation (it loads a bunch of
plugins, which might have their own dependencies etc.). That wouldn't
be nice to people who run svn over ssh and/or don't care about Cyrus
SASL. We could instead do the initialization in sasl_auth_request
using svn_atomic_init_once, like we do on the client side. Thoughts?
> I've got anon-access = none and auth-access = write turned on in
> svnserve.conf, and use-sasl = true set. In my
> /usr/lib/sasl2/Subversion.conf file I have the following:
>
> pwcheck_method: auxprop
> mech_list: DIGEST-MD5 ANONYMOUS
>
> And I gave myself a username and password via saslpasswd2, although I
> haven't actually got myself to the point of being prompted for it.
>
> Other than the crash, a few questions. Why is the config file
> capitalized? Is that a convention with SASL conf files? We've stuck
> to all lowercase so far.
Ok, I'll change it to lowercase.
> Also, why do I have to run saslpasswd2 as
> root? Is that normal? How do people generally control their sasl
> passwords?
I suppose saslpasswd2 is meant to be used by a system administrator.
> Also, one compile warning I noticed. In sasl_auth_request there's the
> following bit of code:
>
> char *p;
> const char *user;
>
> /* Get the authenticated username. */
> result = sasl_getprop(sasl_ctx, SASL_USERNAME, (const void **)&user);
>
> This produces a warning about type punned pointers, you can avoid that
> by passing a const void * instead of user, and then assigning it to
> user later. I also find it a little odd that result is never checked
> in that function...
Yup, I'll have to fix that. Thanks.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 29 20:57:53 2006