[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-08-29 17:00:06 CEST

On 8/21/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> This patch adds Cyrus SASL support to svnserve. Security layers are
> not supported yet - I'll submit another patch for that when this one
> gets the 'stamp of approval'.
> [[[
> * subversion/include/svn_config.h
> * subversion/libsvn_repos/repos.c
> (create_conf): Document the new option.
> * subversion/svnserve/sasl_auth.c: New file.
> * subversion/svnserve/main.c
> (main): Call sasl_init().
> * subversion/svnserve/serve.c:
> (server_baton_t, authn_type, authz_type, get_access): Moved to server.h.
> (simple_auth_request): Contains the code that was prieviously in auth_request.
> (auth_request): Call sasl_auth_request() or simple_auth_request().
> (must_have_access): Consider the value of b->use_sasl when
> determining whether authentication should be performed.
> (find_repos): Read the value of the use-sasl option into b->use_sasl.
> Use that value when determining whether access is allowed to the repository.
> * subversion/svnserve/server.h
> (server_baton_t): Moved here from serve.c. Has a new member 'use_sasl'
> (authn_type, authz_type, get_access): Moved here from serve.c.
> (sasl_init, sasl_auth_request): New declarations.
> ]]]
> SASL supports many password-checking methods. It can use an external
> daemon saslauthd that can authenticate against /etc/shadow, PAM, LDAP,
> etc. It only works with plaintext passwords, though, so we can't use
> it until we have SSL support in for ra_svn. Until then, we have to use
> the other method, auxprop, which fetches passwords from a database
> (which is usually stored in /etc/sasldb2, but could also be an
> external SQL server, or a LDAP database)
> To test this patch, create a configuration file Subversion.conf in
> /usr/lib/sasl2. This file will be read by Cyrus SASL at runtime to
> determine how authentication should be performed.
> See the SASL docs for more details. A simple example could be:
> pwcheck_method: auxprop
> Then add users and passwords to Cyrus SASL's password database:
> saslpasswd2 -c user -u realm -a Subversion
> where 'realm' is the actual realm of your repository.
> Just like Subversion, Cyrus SASL supports the concept of
> "authentication realms". In fact, svnserve will treat the repository
> realm as a SASL realm when authenticating the user. This is necessary
> because the password database is global instead of per-repository, so
> it's the only way for Subversion to tell which users belong to which
> repository.
> Comments and criticism are welcome, as always.

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;
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));
265 /* SASL needs to know if we are externally authenticated. */
266 if (b->tunnel_user)

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

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. Also, why do I have to run saslpasswd2 as
root? Is that normal? How do people generally control their sasl

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...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 29 17:33:55 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.