You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2007/05/26 08:32:34 UTC
SASL for ra_svn on Windows
Hi,
I've just read http://svn.collab.net/repos/svn/trunk/notes/sasl.txt
which mentions the SASL support. I also had a closer look at the SASL
library and got it to compile on Windows. But I can see some serious
problems with that, so I'd like to know if the official command line
client on Windows will be built with SASL support? If yes, which plugins
will be included?
The problems I see with the Cyrus SASL lib are again the same as I had
with the apr-iconv lib: dll hell.
The plugin dlls are loaded from a fixed path and/or from paths specified
in the registry. This will work as long as all plugins are built with
the same c-runtime as the app using them. But only one app is needed
which installs/overwrites the plugin dlls built with e.g. the crt v8
(requires a manifest), and all apps built with older crts can't use them
anymore.
The way I see it right now is that I probably won't link TSVN with SASL
support. But if the CL client will include it, I may have to do it
anyway and pray that I'm not going straight to dll hell.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Daniel Rall <dl...@collab.net>.
On Sat, 26 May 2007, Vlad Georgescu wrote:
> Stefan Küng wrote:
> > D.J. Heap wrote:
> >> On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
> >> [snip]
> >>> That would help, yes. But still not solve the problem: sasl would still
> >>> search the plugins in all the registered paths.
> >>
> >> Hmm, you mean the set_path call just adds that path to the front of
> >> the search list -- it would still search the default install for
> >> plug-ins?
> >
> > I haven't checked the whole source of SASL, but from what I've seen I'd
> > have to say yes. I'm not even sure if set_path will add the path to the
> > front of the list - it could even add the path to the back of that list.
> > I think I'll go with my patch instead, that way I'm sure that the other
> > paths are ignored.
> >
>
> Looking at the Cyrus SASL 2.1.22 sources (specifically the lib/common.c
> file), once you call sasl_set_path() it changes the default path
> callback from _sasl_getpath() (which looks into the registry) to
> _sasl_getpath_simple(), which will simply return the value you provided.
> So it shouldn't look into any other paths than the one you explicitly set.
Good news! This sounds pretty safe -- static linkage doesn't seem
necessary, so long as no one is overwriting your Subversion-specific
SASL DLLs.
Re: SASL for ra_svn on Windows
Posted by Vlad Georgescu <vg...@gmail.com>.
Stefan Küng wrote:
> D.J. Heap wrote:
>> On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
>> [snip]
>>> That would help, yes. But still not solve the problem: sasl would still
>>> search the plugins in all the registered paths.
>>
>> Hmm, you mean the set_path call just adds that path to the front of
>> the search list -- it would still search the default install for
>> plug-ins?
>
> I haven't checked the whole source of SASL, but from what I've seen I'd
> have to say yes. I'm not even sure if set_path will add the path to the
> front of the list - it could even add the path to the back of that list.
> I think I'll go with my patch instead, that way I'm sure that the other
> paths are ignored.
>
Looking at the Cyrus SASL 2.1.22 sources (specifically the lib/common.c
file), once you call sasl_set_path() it changes the default path
callback from _sasl_getpath() (which looks into the registry) to
_sasl_getpath_simple(), which will simply return the value you provided.
So it shouldn't look into any other paths than the one you explicitly set.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Stefan Küng <to...@gmail.com>.
D.J. Heap wrote:
> On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
> [snip]
>>
>> That would help, yes. But still not solve the problem: sasl would still
>> search the plugins in all the registered paths.
>
>
> Hmm, you mean the set_path call just adds that path to the front of
> the search list -- it would still search the default install for
> plug-ins?
I haven't checked the whole source of SASL, but from what I've seen I'd
have to say yes. I'm not even sure if set_path will add the path to the
front of the list - it could even add the path to the back of that list.
I think I'll go with my patch instead, that way I'm sure that the other
paths are ignored.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by "D.J. Heap" <dj...@gmail.com>.
On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
[snip]
>
> That would help, yes. But still not solve the problem: sasl would still
> search the plugins in all the registered paths.
Hmm, you mean the set_path call just adds that path to the front of
the search list -- it would still search the default install for
plug-ins?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Stefan Küng <to...@gmail.com>.
Vlad Georgescu wrote:
[snip]
> So, one way you can isolate yourself from other applications would be to
> install the SASL plugins in a TSVN-specific location and call the
> sasl_set_path() function before doing anything with Subversion, like this:
>
> if (sasl_set_path(SASL_PATH_TYPE_PLUGIN, "your path here") != SASL_OK)
> { /* handle error */ }
That would help, yes. But still not solve the problem: sasl would still
search the plugins in all the registered paths.
And since SASL is for authentication, I don't like the idea that even if
everything goes right with the installation/dll-loading, some other apps
could overwrite some SASL dlls with maybe insecure versions and my app
would then use those. That's also why OpenSSL recommends to not use it
as a dll but link it statically.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by "D.J. Heap" <dj...@gmail.com>.
On 5/26/07, Vlad Georgescu <vg...@gmail.com> wrote:
[snip]
>
> Thanks for the explanation, Stefan.
>
> So, one way you can isolate yourself from other applications would be to
> install the SASL plugins in a TSVN-specific location and call the
> sasl_set_path() function before doing anything with Subversion, like this:
>
> if (sasl_set_path(SASL_PATH_TYPE_PLUGIN, "your path here") != SASL_OK)
> { /* handle error */ }
Ah, perfect -- we should probably do this in the commandline client
and svnserve as well, or at least make it an option they can specify
in the config file. Do you have any concerns about doing that, Vlad?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Vlad Georgescu <vg...@gmail.com>.
Stefan Küng wrote:
> It depends also on the OS version you're using. As I said, it can work
> (depending on some OS settings) on XP and lower. But it won't work on
> Server2003 and Vista for non-admin users (without changing the default
> OS settings).
> Also, httpd.exe runs as a service with the SYSTEM user account, which
> has some more rights than a normal application.
>
> And of course it also depends on where the crt dlls are installed to.
> While it is recommended to install them with the msn (msi merge module)
> provided by MS, it's not required. And some apps will install them on
> their own (not every app uses an msi installer), which usually means the
> crt dll's are *not* installed in the SxS cache of the OS - and then
> you're screwed.
>
> Another thing to remember: apps can get uninstalled. And (as my
> experience clearly shows) they often uninstall the crt dlls too if they
> have them installed before - which means the other apps which correctly
> just increased the install counter of those dlls don't have them anymore.
>
> Also remember that such situations are called "dll hell" - It'which
> means they usually don't happen on the devs computer. Otherwise the s
> hell because you get problems which are hard to diagnose, often don't
> happen immediately but after some time (after users install other tools
> and don't have any problems until they run your app again) and of course
> don't happen on all machines but "just a few". But if you have enough
> users, those "few" can ruin many days and weekends.
Thanks for the explanation, Stefan.
So, one way you can isolate yourself from other applications would be to
install the SASL plugins in a TSVN-specific location and call the
sasl_set_path() function before doing anything with Subversion, like this:
if (sasl_set_path(SASL_PATH_TYPE_PLUGIN, "your path here") != SASL_OK)
{ /* handle error */ }
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Stefan Küng <to...@gmail.com>.
D.J. Heap wrote:
> On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
> [snip]
>> How about setting up a test svnserve with sasl enabled so client devs
>> can test against it? Maybe even multiple setups with different auth
>> types. That would help a lot.
>
>
> Good idea, I can do that. I'll try to get that going this weekend and
> let you know.
That would be great! I then start working on linking TSVN with SASL so I
can try it out right away.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by "D.J. Heap" <dj...@gmail.com>.
On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
[snip]
> How about setting up a test svnserve with sasl enabled so client devs
> can test against it? Maybe even multiple setups with different auth
> types. That would help a lot.
Good idea, I can do that. I'll try to get that going this weekend and
let you know.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Stefan Küng <to...@gmail.com>.
D.J. Heap wrote:
> On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
> [snip]
>> Also remember that such situations are called "dll hell" - It'which
>> means they usually don't happen on the devs computer. Otherwise the s
>> hell because you get problems which are hard to diagnose, often don't
>> happen immediately but after some time (after users install other tools
>> and don't have any problems until they run your app again) and of course
>> don't happen on all machines but "just a few". But if you have enough
>> users, those "few" can ruin many days and weekends.
>
>
> I agree that the one-shared-installation could be a problem. In
> theory, it should be fine, but in practice (at least on Windows which
> is victim to lots of crap installers) it almost never is. And that
> doesn't include any potential crt issues.
>
> I've only looked at the sasl code a bit, but it didn't look like it
> would be too hard to patch it to probe relative paths before looking
> for the 'default' install or something like that.
>
> Would that work for TSVN or do you have another suggestion?
I've already patched the function _sasl_get_default_win_path() to not
use the registry or the fixed path but use GetModuleFileName() to find
out where the calling app is installed and use that path instead.
But while this works with the tool "pluginviewer" which comes with the
cyrus sasl lib, I can't get the testsuite.exe to work.
> I think sasl is going to be a great feature and want to help make sure
> it works well if I can.
How about setting up a test svnserve with sasl enabled so client devs
can test against it? Maybe even multiple setups with different auth
types. That would help a lot.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by "D.J. Heap" <dj...@gmail.com>.
On 5/26/07, Stefan Küng <to...@gmail.com> wrote:
[snip]
> Also remember that such situations are called "dll hell" - It'which
> means they usually don't happen on the devs computer. Otherwise the s
> hell because you get problems which are hard to diagnose, often don't
> happen immediately but after some time (after users install other tools
> and don't have any problems until they run your app again) and of course
> don't happen on all machines but "just a few". But if you have enough
> users, those "few" can ruin many days and weekends.
I agree that the one-shared-installation could be a problem. In
theory, it should be fine, but in practice (at least on Windows which
is victim to lots of crap installers) it almost never is. And that
doesn't include any potential crt issues.
I've only looked at the sasl code a bit, but it didn't look like it
would be too hard to patch it to probe relative paths before looking
for the 'default' install or something like that.
Would that work for TSVN or do you have another suggestion?
I think sasl is going to be a great feature and want to help make sure
it works well if I can.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Stefan Küng <to...@gmail.com>.
Vlad Georgescu wrote:
> Stefan Küng wrote:
>> [...]
>> an app which doesn't have the correct manifest resource can't load a dll
>> which requires the crt v8, because that will only load if the manifest
>> is correct.
>>
>> For example:
>> app built with VS2005 (has the correct manifest)
>> * can load dlls linked with crt v6 (no manifest) or crt v8
>> * can't load dll's linked with crt v7 (built with VS2002/2003)
>>
>> an app built with VC6 (has no manifest at all)
>> * can load dlls linked with crt v6
>> * can *not* load dlls linked with crt v7 or higher versions
>
> I'm not sure I understand. Are you saying that if a plugin dll has a
> manifest resource, it will be ignored? The reason I'm asking is that I
> have a httpd.exe that was built against msvcrt.dll and I can get it to
> load my mod_dav_svn.so linked with msvcrt80d.dll without any problems.
> Am I missing something?
It depends also on the OS version you're using. As I said, it can work
(depending on some OS settings) on XP and lower. But it won't work on
Server2003 and Vista for non-admin users (without changing the default
OS settings).
Also, httpd.exe runs as a service with the SYSTEM user account, which
has some more rights than a normal application.
And of course it also depends on where the crt dlls are installed to.
While it is recommended to install them with the msn (msi merge module)
provided by MS, it's not required. And some apps will install them on
their own (not every app uses an msi installer), which usually means the
crt dll's are *not* installed in the SxS cache of the OS - and then
you're screwed.
Another thing to remember: apps can get uninstalled. And (as my
experience clearly shows) they often uninstall the crt dlls too if they
have them installed before - which means the other apps which correctly
just increased the install counter of those dlls don't have them anymore.
Also remember that such situations are called "dll hell" - It'which
means they usually don't happen on the devs computer. Otherwise the s
hell because you get problems which are hard to diagnose, often don't
happen immediately but after some time (after users install other tools
and don't have any problems until they run your app again) and of course
don't happen on all machines but "just a few". But if you have enough
users, those "few" can ruin many days and weekends.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Vlad Georgescu <vg...@gmail.com>.
Stefan Küng wrote:
> [...]
> an app which doesn't have the correct manifest resource can't load a dll
> which requires the crt v8, because that will only load if the manifest
> is correct.
>
> For example:
> app built with VS2005 (has the correct manifest)
> * can load dlls linked with crt v6 (no manifest) or crt v8
> * can't load dll's linked with crt v7 (built with VS2002/2003)
>
> an app built with VC6 (has no manifest at all)
> * can load dlls linked with crt v6
> * can *not* load dlls linked with crt v7 or higher versions
I'm not sure I understand. Are you saying that if a plugin dll has a
manifest resource, it will be ignored? The reason I'm asking is that I
have a httpd.exe that was built against msvcrt.dll and I can get it to
load my mod_dav_svn.so linked with msvcrt80d.dll without any problems.
Am I missing something?
>
> of course, this also depends on the OS version the apps are used on:
> * Win2k won't be a problem (doesn't know manifests)
> * WinXP shouldn't be a problem with most configurations. But a more
> tighten up system could prevent the dlls from loading properly
> * Win2003/Vista will be a problem
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Stefan Küng <to...@gmail.com>.
Vlad Georgescu wrote:
> Stefan Küng wrote:
>> The problems I see with the Cyrus SASL lib are again the same as I had
>> with the apr-iconv lib: dll hell.
>> The plugin dlls are loaded from a fixed path and/or from paths specified
>> in the registry. This will work as long as all plugins are built with
>> the same c-runtime as the app using them. But only one app is needed
>> which installs/overwrites the plugin dlls built with e.g. the crt v8
>> (requires a manifest), and all apps built with older crts can't use them
>> anymore.
>
> AFAIK this is only a problem if you allocate memory (or any other C
> runtime resource) in the main library and then try to free it in the
> plugin, or vice-versa. If that is the case then we should be fine
> because SASL follows a "if you allocate it, you free it" policy.
I'm not talking about possible memory problems or other things that
could eventually lead to a segfault. I'm talking here about *loading*
the dlls:
an app which doesn't have the correct manifest resource can't load a dll
which requires the crt v8, because that will only load if the manifest
is correct.
For example:
app built with VS2005 (has the correct manifest)
* can load dlls linked with crt v6 (no manifest) or crt v8
* can't load dll's linked with crt v7 (built with VS2002/2003)
an app built with VC6 (has no manifest at all)
* can load dlls linked with crt v6
* can *not* load dlls linked with crt v7 or higher versions
of course, this also depends on the OS version the apps are used on:
* Win2k won't be a problem (doesn't know manifests)
* WinXP shouldn't be a problem with most configurations. But a more
tighten up system could prevent the dlls from loading properly
* Win2003/Vista will be a problem
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SASL for ra_svn on Windows
Posted by Vlad Georgescu <vg...@gmail.com>.
Stefan Küng wrote:
> The problems I see with the Cyrus SASL lib are again the same as I had
> with the apr-iconv lib: dll hell.
> The plugin dlls are loaded from a fixed path and/or from paths specified
> in the registry. This will work as long as all plugins are built with
> the same c-runtime as the app using them. But only one app is needed
> which installs/overwrites the plugin dlls built with e.g. the crt v8
> (requires a manifest), and all apps built with older crts can't use them
> anymore.
AFAIK this is only a problem if you allocate memory (or any other C
runtime resource) in the main library and then try to free it in the
plugin, or vice-versa. If that is the case then we should be fine
because SASL follows a "if you allocate it, you free it" policy.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org