You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2010/07/26 06:30:55 UTC

Re: sasl mechanisms order

CC += dev@

Victor Sudakov wrote on Mon, Jul 26, 2010 at 12:53:44 +0700:
> Daniel Shahaf wrote:
> > > 
> > > I have the following line in /usr/local/lib/sasl2/svn.conf:
> > > mech_list: gssapi digest-md5 anonymous
> > > 
> > > How can I guarantee that the subversion client/server will always use
> > > GSSAPI before DIGEST-MD5? Or a more generic question, how can I change
> > > the order of mechanisms if I have to?
> > > 
> > 
> > Looking at subversion/libsvn_ra_svn/{client.c,cyrus_auth.c}, it seems that the
> > following order is used:
> > 
> > * EXTERNAL (i.e., ssh tunnel)
> > * ANONYMOUS
> > * ${server-reported mechanisms, in the order suggested by the server}
> > * CRAM-MD5 (used via internal_auth.c even if SASL doesn't support it)
> > 
> > I don't see a knob that lets you manipulate the order.
> 
> Then how can I manipulate "the order suggested by the server"? The
> server is svnserve.
> 

Looking in subversion/svnserve/cyrus_auth.c, the list of mechansms is obtained
directly from SASL:

    [[[
    /* Get the list of mechanisms. */
    result = sasl_listmech(sasl_ctx, NULL, NULL, " ", NULL,
                           &mechlist, NULL, &mech_count);

    if (result != SASL_OK)
      return fail_cmd(conn, pool, sasl_ctx);

    if (mech_count == 0)
      {
        svn_error_t *err = svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
                                            _("Could not obtain the list"
                                            " of SASL mechanisms"));
        SVN_ERR(write_failure(conn, pool, &err));
        return svn_ra_svn_flush(conn, pool);
      }

    /* Send the list of mechanisms and the realm to the client. */
    SVN_ERR(svn_ra_svn_write_cmd_response(conn, pool, "(w)c",
                                          mechlist, b->realm));
    ]]]

so you'd have to look up in the SASL docs how to configure the ordering of
mechanisms.  (I don't know offhand how to configure that.)


What bothers me, however, is why the svn_ra_svn_write_cmd_response() call
seems to write only the first mechanism to the client?

Re: sasl mechanisms order

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alec Kloss wrote on Tue, Jul 27, 2010 at 12:42:11 -0500:
> I'd dread the day someone changed the Cyrus SASL Makefile and got them
> installed in reverse order.

Personally, I'd just assume the order is "arbitrary" and not rely on it to have
any particular rule behind it.

Re: sasl mechanisms order

Posted by Alec Kloss <al...@oracle.com>.
On 2010-07-27 09:14, Victor Sudakov wrote:
[chop]
> Thank you for having found this out. This is truly amazing. This means
> that if perchance I touch a file in /usr/local/lib/sasl2/, my Kerberos
> SSO can stop working?
[chop]

Well, that's pretty unlikely.  It's moderately difficult to re-arrange
the order of files in a directory.  Assuming you're installing using a
packaging system that removes old version prior to installing new ones
and only does reasonable things with file creation order, your
/usr/local/lib/sasl2 directory should start empty and then get the
gssapi module installed after the digest-md5 module (probably because of
the order they're declared in the Makefile for Cyrus sasl).  Now if you
were creating and deleting a bunch of other files in that directory and
then installing sasl into that directory... bad things might happen to
you.  It's even possible if you have some perverse backup software.  But
anyway it's still definitely not a good thing.  I'd dread the day
someone changed the Cyrus SASL Makefile and got them installed in
reverse order.

-- 
Alec.Kloss@oracle.com     The views expressed are my own and 
do not necessarily reflect the views of Oracle.  PGP key at
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEBD1FF14

Re: sasl mechanisms order

Posted by Victor Sudakov <su...@sibptus.tomsk.ru>.
Daniel Shahaf wrote:
> > So we seem to have a stalemate situation. The SASL library believes
> > the client should select the preferred mechanism, whereas the Subversion
> > client relies on "the order suggested by the server". Brilliant.
> 
> It would be more constructive to summarize the problem on the dev@
> list so that you or someone else can resolve it.

I have. Please follow up in dev@

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru

Re: sasl mechanisms order

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Victor Sudakov wrote on Tue, Jul 27, 2010 at 09:14:42 +0700:
> So we seem to have a stalemate situation. The SASL library believes
> the client should select the preferred mechanism, whereas the Subversion
> client relies on "the order suggested by the server". Brilliant.

It would be more constructive to summarize the problem on the dev@ list so that
you or someone else can resolve it.

Re: sasl mechanisms order

Posted by Victor Sudakov <su...@sibptus.tomsk.ru>.
Alec Kloss wrote:

[dd]

> 
> As far as I can tell (and as amazing as this sounds), the order of the
> offered mechanisms from Cyrus sasl is, by default, the reverse of the
> order that the library finds them.  This would be, in effect, the
> reverse physical directory order of the modules in
> /usr/[local]/lib/sasl2/ which you can find with ls -U.  I've confirmed
> this by making copies and deletes of the .so files in that directory to
> rearrange the ordering.   The list is reversed from the order they're
> found in because mechanism list is a linked list and new entries are
> prepened (around server.c:392).  

Thank you for having found this out. This is truly amazing. This means
that if perchance I touch a file in /usr/local/lib/sasl2/, my Kerberos
SSO can stop working?

> 
> As the link your provided mentions, Cyrus SASL believes it's the client
> that should select the preferred mechanism from the list offered by the
> server, not just the first one.  

So we seem to have a stalemate situation. The SASL library believes
the client should select the preferred mechanism, whereas the Subversion
client relies on "the order suggested by the server". Brilliant.


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru

Re: sasl mechanisms order

Posted by Alec Kloss <al...@oracle.com>.
On 2010-07-26 14:30, Victor Sudakov wrote:
> Daniel Shahaf wrote:
> > > > > 
> > > > > I have the following line in /usr/local/lib/sasl2/svn.conf:
> > > > > mech_list: gssapi digest-md5 anonymous
> > > > > 
> > > > > How can I guarantee that the subversion client/server will always use
> > > > > GSSAPI before DIGEST-MD5? Or a more generic question, how can I change
> > > > > the order of mechanisms if I have to?
> > > > > 
> > > > 
> > > > Looking at subversion/libsvn_ra_svn/{client.c,cyrus_auth.c}, it seems that the
> > > > following order is used:
> > > > 
> > > > * EXTERNAL (i.e., ssh tunnel)
> > > > * ANONYMOUS
> > > > * ${server-reported mechanisms, in the order suggested by the server}
> > > > * CRAM-MD5 (used via internal_auth.c even if SASL doesn't support it)
> > > > 
> > > > I don't see a knob that lets you manipulate the order.
> > > 
> > > Then how can I manipulate "the order suggested by the server"? The
> > > server is svnserve.
> > > 
> > 
> > Looking in subversion/svnserve/cyrus_auth.c, the list of mechansms is obtained
> > directly from SASL:
> 
> [dd]
> 
> > 
> > so you'd have to look up in the SASL docs how to configure the ordering of
> > mechanisms.  (I don't know offhand how to configure that.)
> 
> I was unable to find this in the SASL docs. It only says that
> mech_list is a "Whitespace separated list of mechanisms to allow (e.g.
> 'plain otp'). Used to restrict the mechanisms to a subset of the
> installed plugins."
> 
> While googling I found even such statements as 
> http://www.techienuggets.com/CommentDetail?tx=188636
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:sudakov@sibptus.tomsk.ru
> 

As far as I can tell (and as amazing as this sounds), the order of the
offered mechanisms from Cyrus sasl is, by default, the reverse of the
order that the library finds them.  This would be, in effect, the
reverse physical directory order of the modules in
/usr/[local]/lib/sasl2/ which you can find with ls -U.  I've confirmed
this by making copies and deletes of the .so files in that directory to
rearrange the ordering.   The list is reversed from the order they're
found in because mechanism list is a linked list and new entries are
prepened (around server.c:392).  

As the link your provided mentions, Cyrus SASL believes it's the client
that should select the preferred mechanism from the list offered by the
server, not just the first one.  


-- 
Alec.Kloss@oracle.com     The views expressed are my own and 
do not necessarily reflect the views of Oracle.  PGP key at
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEBD1FF14

Re: sasl mechanisms order

Posted by Victor Sudakov <su...@sibptus.tomsk.ru>.
Daniel Shahaf wrote:
> > > > 
> > > > I have the following line in /usr/local/lib/sasl2/svn.conf:
> > > > mech_list: gssapi digest-md5 anonymous
> > > > 
> > > > How can I guarantee that the subversion client/server will always use
> > > > GSSAPI before DIGEST-MD5? Or a more generic question, how can I change
> > > > the order of mechanisms if I have to?
> > > > 
> > > 
> > > Looking at subversion/libsvn_ra_svn/{client.c,cyrus_auth.c}, it seems that the
> > > following order is used:
> > > 
> > > * EXTERNAL (i.e., ssh tunnel)
> > > * ANONYMOUS
> > > * ${server-reported mechanisms, in the order suggested by the server}
> > > * CRAM-MD5 (used via internal_auth.c even if SASL doesn't support it)
> > > 
> > > I don't see a knob that lets you manipulate the order.
> > 
> > Then how can I manipulate "the order suggested by the server"? The
> > server is svnserve.
> > 
> 
> Looking in subversion/svnserve/cyrus_auth.c, the list of mechansms is obtained
> directly from SASL:

[dd]

> 
> so you'd have to look up in the SASL docs how to configure the ordering of
> mechanisms.  (I don't know offhand how to configure that.)

I was unable to find this in the SASL docs. It only says that
mech_list is a "Whitespace separated list of mechanisms to allow (e.g.
'plain otp'). Used to restrict the mechanisms to a subset of the
installed plugins."

While googling I found even such statements as 
http://www.techienuggets.com/CommentDetail?tx=188636

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru