Windows 7 / UAC / Permission question

DarkRuleR · Post by *DarkRuleR » 2010-01-31, 10:55 UTC

Hello,

I have installed TC in: "C:\Program Files (x86)\totalcmd"
.ini files location: "C:\Users\<user name>\AppData\Roaming\GHISLER"
OS: Windows 7 Ultimate 64bits

This works great except that TC can't use libeay32.dll & libssl32.dll stored in the TC map.
(i know for sure they are there)

Must be some permission & UAC thing?

I don't want to give my default user "Full control" permissions on the TC map.
Or turn off UAC.
(I kind of like the Windows 7 version approch)

Any idea's????

Greetz,

DR...

MVV · Post by *MVV » 2010-01-31, 13:03 UTC

Please check paths where libraries are searched. Maybe it's because %ProgramFiles% is different for 32 and 64-bit executables? Try to move TC folder to e.g. root (C:\totalcmd) and look what happens. And, where theese DLLs are placed? Are they 64-bit?

DarkRuleR · Post by *DarkRuleR » 2010-02-01, 17:13 UTC

MVV wrote:Please check paths where libraries are searched. Maybe it's because %ProgramFiles% is different for 32 and 64-bit executables?

I checked with sysinternals process monitor and TC tries to load the files from the correct location.

MVV wrote: Try to move TC folder to e.g. root (C:\totalcmd) and look what happens.

I tried but the same result.
Very strange the root should be UAC free?!

MVV wrote: And, where theese DLLs are placed? Are they 64-bit?

The DLL are placed in the same map as TC: "C:\Program Files (x86)\totalcmd".
And I think they are 32-bit versions.

I forgot to tell that I got a working situation on my primairy system using the same .dll files.
Also Windows 7 Ultimate 64-bit.
On that system I did an installation in: "C:\Program Files (x86)\totalcmd" and also put my .ini files there.
Default the logged in user does not have write permissions on that map.
So as quick and dirty solution I added full control permissions on the TC map for the group Users.
This works perfect.
But I don't like this solutions.

Greetz,

DR...

MVV · Post by *MVV » 2010-02-01, 18:21 UTC

That's strange because applications don't require elevation to load DLLs... UAC is not the reason (maybe)...

karlchen · Post by *karlchen » 2010-02-01, 22:10 UTC

Hello, DarkRuleR.

I may have missed it. Yet, I do not find any error message which you receive that tells you the DLLs cannot be loaded or cannot be accessed. How do you know they cannot be accessed?

Kind regards,
Karl

DarkRuleR · Post by *DarkRuleR » 2010-02-02, 09:24 UTC

MVV wrote:That's strange because applications don't require elevation to load DLLs... UAC is not the reason (maybe)...

Indeed very strange!
I've also tried starting TC elevated.
But same error.

DarkRuleR · Post by *DarkRuleR » 2010-02-02, 09:25 UTC

karlchen wrote:Hello, DarkRuleR.

I may have missed it. Yet, I do not find any error message which you receive that tells you the DLLs cannot be loaded or cannot be accessed. How do you know they cannot be accessed?

Kind regards,
Karl

Hi Karl,

I get this error message:
"OpenSSL library not found!
To use SSL connections, please download the OpenSSL DLLs from the internet and put them in the Total Commander directory!"

Greetz,

DR...

karlchen · Post by *karlchen » 2010-02-02, 22:08 UTC

Hello, DarkRuleR.

Thanks for posting the error message.

Hm, as a matter of fact the phrase

"OpenSSL library not found!
To use SSL connections, please download the OpenSSL DLLs from the internet and put them in the Total Commander directory!"

is vague enough to imagine that different causes could lead to this error message.

It is imaginable that access rights are involved. (Unlikely, because T.C. loads fine from its programme folder, doesn't it.)

It is also imaginable that for whichever reason the DLLs libeay32.dll and libssl32.dll are not really detected inside %COMMANDER_PATH% although they are there.
(You stated that they indeed live inside the Total Commander programme folder.)
I really wonder whether some kind of automatic folder redirection could be involved here - though in fact it should not be.

I will see whether the error can be reproduced on a Windows 2008 R2 system (64bit). Sorry, no Windows 7 64bit is available to me.

Kind regards,
Karl

karlchen · Post by *karlchen » 2010-02-03, 11:37 UTC

Hello, DarkRuleR.

Windows 2008 R2, 64bit:

T.C. 7.50a has been installed to the same location that you named in your initial post, i.e. "C:\Program files (x86)\Totalcmd".
"%appdata%\Ghisler" has been configured as the location for my INI files.
The libcurl v17.9.6 DLLs
+ libeay32.dll 1.554.920 27.03.2009 13:02 -a--
+ libssl32.dll 332.254 27.03.2009 13:02 -a--
have been stored inside %COMMANDER_PATH%
Just ticking the [x] SSL/TLS option inside the FTP configuration dialogue box is enough to reproduce the error message which you quoted.

So the problem is reproducible.

Went to my local machine, Windows XP Prof SP2, 32bit:

T.C. 7.50a has been installed to "C:\Programme\Totalcmd".
"%userprofile%" has been configured as the location for my INI files.
The SFTP v0.94 plugin has been installed to "%COMMANDER_PATH%\Plugins\SFTP". I.e. the libcurl v17.9.6 DLLs
+ libeay32.dll 1.554.920 27.03.2009 13:02 -a--
+ libssh2.dll 180.736 16.08.2009 14:55 -a--
are present there. (no libssl32.dll, not needed for SFTP)
Ticking the [x] SSL/TLS option inside the FTP configuration dialogue box yields the the error message which you quoted.
This was to be expected, because the libssl32.dll was still missing.
libssl32.dll has been put to the SFTP plugin folder (!), not even to the %COMMANDER_PATH%.
+ libssl32.dll 332.254 27.03.2009 13:02 -a--
Now FTPS works. No complaint about any missing OpenSSL libraries.

Further tests should help find out whether the following factors are relevant in order to reproduce/solve the problem:
+ Windows 64bit vs 32bit
+ Automatic folder redirection
+ Different access rights to "COMMANDER_PATH%
+ Spaces in the fully qualified %COMMANDER_PATH%

Therefore I will try to make FTPS work on
+ Windows 2003 Std, SP2, 32bit, enu.
+ Windows 2003 Std, SP2, 64bit, enu.
+ Windows Vista Home Premium, 32bit, ger.

I'll report back later ....
Karl
--
<corrected> typing error </corrected>

karlchen · Post by *karlchen » 2010-02-03, 12:15 UTC

Hi, DarkRuleR.

FTPS on Windows 2008 R2 64bit works! No more complaints about missing OpenSLL DLLs.

What has been done?
Not much really:

The SFTP v0.94 plugin has been installed to %COMMANDER_PATH%\plugin\SFTP like on the WinXP machine.
The libssl32.dll has been moved to this folder. So there is no more libssl32.dll inside %COMMANDER_PATH% at all. The libeay32.dll has been removed from %COMMANDER_PATH% as well, because it is present inside the SFTP plugin folder anyway.
So the folder %COMMANDER_PATH%\plugins\SFTP holds these files:
libeay32.dll 1,554,920 03/27/2009 13:02 -a--
libssh2.dll 180,736 08/16/2009 14:55 -a--
libssl32.dll 332,254 03/27/2009 13:02 -a--
sftpplug.wfx 184,320 05/14/2009 22:53 -a--
Only the DLLs in bold letters are needed for FTPS.
FTPS works (SFTP, too, but this is a different story.)

No access rights have been modified. Nothing changed except what has been explained above.

Too bad! Rejoyced too early!
FTPS can work, but it may fail, too.

When will it work:
It works in case your current folder is the folder where the libcurl DLLs live. In my case, FTPS works provided I launch FTPS from the folder %COMMANDER_PATH%\plugins\SFTP.

When will it fail:
It will fail with the well-known error message in all cases where the current folder is not the folder where the libcurl DLLs have been stored.

This suggests that on Windows 2008 R2, 64bit, very likely on Windows 7 64bit, too, Windows performs some dirty little tricks when 32bit programmes try to load 32bit DLLs and try to find them without prefixing the fully qualified pathnames. (Just a guess, but not too wild a guess.)

---Added---
Weird. On Windows 2003 Std SP2 64bit, FTPS seems to work fine provided the 2 DLLs libeay32.dll and libssl32.dll live in the %COMMANDER_PATH% folder. - This is how it should be.

---Added #2---
Weird. On Windows 2008 R2 64bit, FTPS seems to work fine provided the 2 DLLs libeay32.dll and libssl32.dll live in the %COMMANDER_PATH% folder and provided %COMMANDER_PATH% is not a sub-folder of either "C:\Program Files" or "C:\Program Files (x86)". - But we knew this before, didn't we.

---Added #3---
Still weirder. On Windows 2008 R2 64bit, the foldertree "totalcmd" has been moved back to "C:\Program Files (x86)" with the help of Windows Explorer. FTPS still works correctly. libeay32.dll and libssl32.dll still live in the %COMMANDER_PATH% folder.
Checked the effective privileges and detected that my account had got full control over the moved folder "totalcmd" and all objectes inside.

So basically I am back to the location where I started in my previous post and where I could reproduce the error, but now it works. One difference is that at the beginning T.C. had been installed to the folder, now it has been moved there from c:\utils.

Cheers,
Karl
--
<corrected> typing error </corrected>

DarkRuleR · Post by *DarkRuleR » 2010-02-03, 18:40 UTC

Hello Karl,

Wow you did a great research!!!
It gave me a lot to think about.
Thanx.

And I got it working but don't know why it works.

Windows 7 Ultimate 64bit:

- TC 7.50a has been installed in: "C:\Program files (x86)\totalcmd".
- "%appdata%\Ghisler" has been configured as the location for my INI files

When I copy the "libeay32.dll" and "libssl32.dll" from "curl-7.19.7-devel-mingw32.zip" (like your tests) to the "%COMMANDER_PATH%" everything works perfect?!?!
(when you copy the files you get the message that you need to provide administrator permission)

But when I copy (with tc or explorer) my backup "libeay32.dll" and "libssl32.dll" (the same ones I use on my primary system) to the "%COMMANDER_PATH%" I still get the error.

I've tried switching the location of my backup files.
At first they were located in "D:\e6600_backup\Program Files\totalcmd" so I thought maybe it's the "Program Files" in the path that is the problem.
But even when I zip the files and put them in "E:\" no go.

They are flagged as "evil" or something.

Any idea on that???

I also did a file compare between the "libeay32.dll" and "libssl32.dll" files on my primary system and the "problem" system the are identical!

Greetz,

DR...

Post by *ghisler(Author) » 2010-02-04, 17:20 UTC

Maybe some of these DLLs on your system require the Visual C 2008 runtime? There are definitely some openssl or openssh dlls out there which have this requirement. You can use the fileinfo Lister plugin to see what dlls are needed by a program or dll.

karlchen · Post by *karlchen » 2010-02-04, 22:43 UTC

Hello, Christian.

I can assure you that the OpenSSL DLLs which I use are the ones that you recommend in this thread: New SFTP plugin available now. To be precise the files have been taken from this download package: curl-7.19.6-devel-mingw32.zip.
+ libeay32.dll 1.554.920 27.03.2009 13:02 -a-- (needed for both)
+ libssh2.dll 180.736 16.08.2009 14:55 -a-- (needed for SFTP)
+ libssl32.dll 332.254 27.03.2009 13:02 -a-- (needed for FTPS)

As these DLLs work flawlessly on various Windows systems - Windows XP Prof SP2 (32bit), Windows 2003 Std SP2 (32bit/64bit) and Vista Home Premium (32bit) - I tend to put the blame on some peculiarity to be found on Windows 7 (64bit) and Windows Server 2008 R2 (64bit). - Yet, I admit this is only a personal feeling, no hard facts to support this is so.

OK, I will use fileinfo in order to find out whether libeay32.dll and libssl32.dll depend on some missing VC 2008 runtime files. - Though in this case they should fail all the time no matter where T.C. has been installed to.

Kind regards,
Karl

DarkRuleR · Post by *DarkRuleR » 2010-02-05, 18:05 UTC

ghisler(Author) wrote:Maybe some of these DLLs on your system require the Visual C 2008 runtime? There are definitely some openssl or openssh dlls out there which have this requirement. You can use the fileinfo Lister plugin to see what dlls are needed by a program or dll.

Hi!

I viewed the "bad" dll files with fileinfo:

Dll Dependency

libeay32.dll
+ C:\Windows\system32\WSOCK32.dll
+ C:\Windows\system32\GDI32.dll
+ C:\Windows\system32\ADVAPI32.dll
+ C:\Windows\system32\USER32.dll
+ C:\Windows\system32\KERNEL32.dll

libssl32.dll
+ C:\Program Files (x86)\totalcmd\LIBEAY32.dll
+ C:\Windows\system32\MSVCR71.dll
+ C:\Windows\system32\KERNEL32.dll

So it looks like libssl32.dll points to "C:\Windows\system32\MSVCR71.dll"
This file was not present on the machine with the error.

This seems to be the problem/solution in my case!

The dll files from "curl-7.19.7-devel-mingw32.zip" point to "MSVCRT.dll" but I guess the are allways present in Windows xxx ???

Greetz,

DR...

karlchen · Post by *karlchen » 2010-02-05, 22:04 UTC

Hi, DarkRuleR.

Good finding.

Yes, msvcrt.dll will be present on all Windows systems. MSVCR71.DLL may not be part of a fresh Windows installation. Yet, it can be found pretty frequently in %windir%\system32. So there may be quite a few installation packages which will install it in case it does not exist.

This may explain why on most machines, FTPS using the libcurl DLLS v7.19.6 simply works: unless it is a pretty clean Windows installation, chances are good that some other software has put MSVCR71.DLL into %windir%\system32.

The Windows 2008 Server where FTPs fails as often as it works is a pretty new system with not too many additional software products on it. So MSVCR71.DLL may be absent from %windir%\system32 (%windir%\syswow64 really). I will check that.

If your finding that the libcurl DLLs v7.19.7 do not depend on MSVCR71.DLL is correct, then the solution should be easy: upgrade the DLLs to libcurl v7.19.7.

Kind regards,
Karl