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

Re: [PATCH] sasl service name for svnserve

From: 'Stefan Sperling' <stsp_at_elego.de>
Date: Tue, 4 May 2010 16:14:59 +0200

On Tue, Apr 13, 2010 at 10:33:47AM +0600, Катаргин Алексей wrote:
> -----Original Message-----
> From: 'Stefan Sperling' [mailto:stsp_at_elego.de]
> Sent: Monday, April 12, 2010 10:05 PM
> To: Катаргин Алексей
> Cc: dev_at_subversion.apache.org; noc_at_chelcom.ru
> Subject: Re: [PATCH] sasl service name for svnserve
>
> > On Mon, Apr 12, 2010 at 10:33:03AM +0600, Катаргин Алексей wrote:
> > > -----Original Message-----
> > > From: Stefan Sperling
> > > >The patch looks technically correct, but I don't understand why it is
> > > >needed. Can you explain why it is needed?
> > > >
> > > >It sounds to me as if you'd like to forward authentication requests
> > > >from SASL to PAM. Why can't you achieve this by configuring SASL
> > > >appropriately, without changing svn?
> > > >
> > > > (Note: I don't know much about SASL).
> > > >
> > > >Thanks,
> > > >Stefan
> > >
> > > It's used to set access rights per each repository via chain sasl->pam
> >
> > Can you provide more details? What problem are you trying to solve?
> >
> > I know virtually *nothing* about SASL and PAM. In fact, no active developers
> > of svn know about SASL (the person who added SASL support isn't active
> > anymore). That's why your patch hasn't been looked at so far. I'm tyring
> > to review it, but I lack the necessary knowledge to do so. You'll have
> > to teach me to understand the purpose of your patch.
> >
> > So, based on me knowing nothing at all, please explain:
> > - your SASL and PAM setup
> > - what problem existed in your SASL/PAM setup that prompted you
> > to write the patch
> > - why you think the patch is the right way to fix this problem
> > - can you think of any alternative approaches of fixing this problem?
> >
> > It needs more than one sentence to explain all this, sorry.
> > But we'll need your help to understand your contribution.
> > Otherwise it will likely end up not being committed until someone
> > who knows SASL can explain to us why your patch is a good idea,
> > or until I found enough time to learn enough about SASL and PAM
> > so I can make my own judgement.
> >
> > Thanks,
> > Stefan
>
> Let me explain.
> The real chain of authentication is slightly longer.
> "svnserve -> sasl -> pam -> pam_radius -> radius"
> I will not say anything about of the radius config
> in this message.
>
> The goal was to ensure that authentication in radius
> assisted with the service name is assigned to the
> repository.
> Service name used in radius to AUTHORIZE user, not only
> authenticate by login and password!
> The easiest way was to send auth through sasl,
> and then to pam, and then in radius and with all
> this is to pass the service name.
>
> If it is not enough, ask me something specific.

From what I've gathered so far by reading SASL RFCs and Cyrus SASL
documentation, the service name is supposed to be assigned by the IANA:
http://www.iana.org/assignments/gssapi-service-names/
While "svn" isn't registered there, I wonder why the name needs to be
configurable to solve your problem. The SASL specification does not
seem to assume that users would ever need to change the service name.

Let me try to explain what I think your setup looks like:
You have multiple SASL configuration files, one per repository:

/usr/lib/sasl2/svn-repository1.conf
    pwcheck_method: saslauthd
    mech_list: PLAIN
/usr/lib/sasl2/svn-repository2.conf
    pwcheck_method: saslauthd
    mech_list: PLAIN
... and so on.

Usually, Subversion uses "svn" as the service name, so Cyrus will use
the /usr/lib/sasl2/svn.conf configuration file. With your patch, SASL
looks up a different configuration file depending on which repository
is being accessed, /usr/lib/sasl2/svn-repository1.conf,
/usr/lib/sasl2/svn-repository2.conf, etc.

SASL then passes authentication requests to PAM via saslauthd.
PAM uses the service name as a key into its own configuration,
eventually authenticating and authorising the user via RADIUS.
You want PAM to talk to RADIUS in different ways depending on which
repository the user is trying to access.

Have I understood correctly?

Now, it seems to me that creating a new SASL configuration file for each
repository is not how SASL is intended to be used.
It seems that your problem could be solved by using a separate
authentication realm for each Subversion repository (the realm can
be set in $repository/conf/svnserve.conf). Because from what I've read
it seems that when PAM receives the authentication request for service
"svn" from saslauthd, it also receives information about the realm.
Can't PAM use the realm to tell repositories apart from one another,
and then forward the authentication request to RADIUS accordingly?

Thanks,
Stefan
Received on 2010-05-04 16:15:34 CEST

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