More SSL questions..

Did we ever find the solution to this, or did anyone find the cause?

---------------------------------------------------------------------------

T.J. wrote:

Having some problems (still, hehe) getting SSL to work properly on
windows in the new 8.0 (all vers) environment (where cert/key is required).

On the client side when not finding the certificate/key psql would
report the SSL error sslv3 alert handshale failure. After I figured out
where psql was looking for the files and placing them there I now get
the error: SSL SYSCALL error: Connection reset by peer
(0x00002746/10054). On the server side it still reports that the peer
did not return a certificate.

I am able to connect to the server just fine using the same
certificate/key on a linux machine...so I'm guessing it's just another
good ol' windows issue? :)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Not to my knowledge. By the way, for future reference on windows it
looks for the cert/key in the linux equivalent of
`pwd`/.postgresql/postgresql.crt/key, instead of
$HOME/.postgresql/postgresql.crt/key. Maybe you already knew this but I
had to do testing to figure it out so hopefully that bit of knowledge
will be of use to someone else :)

I tried looking through the source myself for the cause of this problem
but I guess there's a reason my perl is so sharp and c so rusty these days..

Don't know if it makes much difference but I have built with vcwin and
mingw with the same resulting error.

Bruce Momjian wrote:

"T.J." <tjtoocool@phreaker.net> writes:

Not to my knowledge. By the way, for future reference on windows it
looks for the cert/key in the linux equivalent of
`pwd`/.postgresql/postgresql.crt/key, instead of
$HOME/.postgresql/postgresql.crt/key.

Actually, it asks getpwuid() for the user's home directory,
rather than looking for an environment variable named HOME.
See client_cert_cb() in fe-secure.c.

This could probably be documented better, but I'm not sure how.
The average user is even less likely to be familiar with getpwuid()
than $HOME, so it doesn't seem like referencing that library function
is much of an improvement.

regards, tom lane

After some more screwing around, I'm not entirely certain windows is
even trying to open my certs. After repeatedly trying to connect it
seemed like I was getting an equal amount of the sslv3 and SSL SYSCALL
errors, whether or not the certs were (where I thought?) windows was
looking for them..

Which leads me to my next question; that function client_cert_cb, does
it ever get executed on windows? :)

I mean, that's the function with the useful error messages (that helped
me on linux), is it not? And the error messages on windows are anything
but useful...and at the beginning of that function there is a:

#ifdef WIN32
return 0;
#else
... (function)
return 1;
#endif

Tom Lane wrote:

"T.J." <tjtoocool@phreaker.net> writes:

Which leads me to my next question; that function client_cert_cb, does
it ever get executed on windows? :)

Um. Looks like someone ifdef'd it out :-(. In fact, if you look
through fe-secure.c, you'll see that just about all the SSL code is
ifdef'd out on Windows.

Try removing the #ifs and see if it compiles.

win32 hackers, anyone know why it's like this?

regards, tom lane

Yeah I already tried removing the ifdef's...oh BOY was it not happy :'(

Tom Lane wrote:

I wrote:

win32 hackers, anyone know why it's like this?

Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.

Does Windows even have a concept of home directory? What would be a
reasonable equivalent to ~/.postgresql/ ?

regards, tom lane

Tom Lane wrote:

I wrote:

win32 hackers, anyone know why it's like this?

Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.

Does Windows even have a concept of home directory? What would be a
reasonable equivalent to ~/.postgresql/ ?

The versions of windows that the port supports (NT4, 2000, 2003, XP) do
have home directories. The "Documents and Settings" (except NT 4 which
uses "Profiles") directory in windows is like /home in Unix. Using my
XP Pro box, I see two relevant environment variables HOMEDRIVE, and
HOMEPATH. On my box they are set as follows:
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\matthew
So: ~/.postgresql/ = C:\Documents and Settings\matthew\.postgresql\

Hope that helps.

Matthew

Tom Lane wrote:

I wrote:

win32 hackers, anyone know why it's like this?

Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.

Does Windows even have a concept of home directory?

Yes, from the shell it would be:

%HOMEDRIVE%
%HOMEPATH%

I believe.

Sincerely,

Joshua D. Drake

What would be a

reasonable equivalent to ~/.postgresql/ ?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

"Matthew T. O'Connor" <matthew@zeut.net> writes:

Tom Lane wrote:

Does Windows even have a concept of home directory? What would be a
reasonable equivalent to ~/.postgresql/ ?

The versions of windows that the port supports (NT4, 2000, 2003, XP) do
have home directories.

OK ... are you supposed to find it out by looking at the environment
vars, or is there another API defined?

I am planning to consolidate the platform dependency into a function
defined like

static bool pqGetHomeDirectory(char *buf, int bufsize)
{
-- Obtain pathname of user's home directory, store in
-- buf[] (of size bufsize)
-- Return TRUE if succeeded, FALSE if not
}

If someone can whip up and test a WIN32 version of this, I'll take care
of the rest.

regards, tom lane

Tom Lane wrote:

OK ... are you supposed to find it out by looking at the environment
vars, or is there another API defined?

I am planning to consolidate the platform dependency into a function
defined like

static bool pqGetHomeDirectory(char *buf, int bufsize)
{
-- Obtain pathname of user's home directory, store in
-- buf[] (of size bufsize)
-- Return TRUE if succeeded, FALSE if not
}

If someone can whip up and test a WIN32 version of this, I'll take care
of the rest.

I can't do the coding, but I took a quick look at msdn and I think this
is relevant:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderpath.asp

HRESULT SHGetFolderPath(
HWND /hwndOwner/,
int /nFolder/,
HANDLE /hToken/,
DWORD /dwFlags/,
LPTSTR /pszPath/
);

Also, for nFolder, it looks like the we want to use a value of
CSIDL_PROFILE (0x0028).

Hope that helps someone out there.

Matthew

Matthew T. O'Connor wrote:

Tom Lane wrote:

If someone can whip up and test a WIN32 version of this, I'll take care
of the rest.

I can't do the coding, but I took a quick look at msdn and I think
this is relevant:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderpath.asp

HRESULT SHGetFolderPath( HWND /hwndOwner/,
int /nFolder/,
HANDLE /hToken/,
DWORD /dwFlags/,
LPTSTR /pszPath/
);

Also, for nFolder, it looks like the we want to use a value of
CSIDL_PROFILE (0x0028).

Er, I don't think so. MSDN says:

CSIDL_PROFILE (0x0028)
Version 5.0. The user's profile folder. A typical path is
C:\Documents and Settings\username. Applications should not create files
or folders at this level; they should put their data under the locations
referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA.

I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
Windows hitters will know better than I do.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
Windows hitters will know better than I do.

Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
"home directory". In particular ~/.pgpass is sought there, and psql
also uses get_home_path in a lot of places.

Seems like we should be consistent about this --- either we trust $HOME
or we don't.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
Windows hitters will know better than I do.

Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
"home directory". In particular ~/.pgpass is sought there, and psql
also uses get_home_path in a lot of places.

Seems like we should be consistent about this --- either we trust $HOME
or we don't.

more fun. I just checked the environment of the postmaster service on a
win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
Settings\postgres"...

For services that are running as 'NT AUTHORITY\SYSTEM', the profile is
"C:\Documents and Settings\Default User" (and the USERDOMAIN and USERNAME
aren't set at all)...

John R Pierce <pierce@hogranch.com> writes:

Tom Lane wrote:

Seems like we should be consistent about this --- either we trust $HOME
or we don't.

more fun. I just checked the environment of the postmaster service on a
win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
Settings\postgres"...

For services that are running as 'NT AUTHORITY\SYSTEM', the profile is
"C:\Documents and Settings\Default User" (and the USERDOMAIN and USERNAME
aren't set at all)...

Actually, the server doesn't depend on home directories in any way shape
or form. The places that we are concerned about are on the client side,
either in libpq or in psql. So what we have to think about is the
environment that libpq might see.

regards, tom lane

win2000 Pro system (using www.sysinternals.com's excellent Process
Explorer tool, btw). HOME is not set. USERPROFILE is set to
"C:\Documents and Settings\postgres"...

For services that are running as 'NT AUTHORITY\SYSTEM', the profile is
"C:\Documents and Settings\Default User" (and the USERDOMAIN and
USERNAME aren't set at all)...

this is also set on XP Pro, except for the 'SYSTEM' services, its "C:\Documents
and Settings\LocalServices"

On Win2000 Server, its the same, except the default profiles are
\winnt\profiles\%username%

Actually, the server doesn't depend on home directories in any way shape
or form. The places that we are concerned about are on the client side,
either in libpq or in psql. So what we have to think about is the
environment that libpq might see.

libpq could be called from a service, such as inetinfo (IIS)...

Tom Lane wrote:

John R Pierce <pierce@hogranch.com> writes:

more fun. I just checked the environment of the postmaster service on a
win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
Settings\postgres"...

Actually, the server doesn't depend on home directories in any way shape
or form. The places that we are concerned about are on the client side,
either in libpq or in psql. So what we have to think about is the
environment that libpq might see.

Right but I think the point is that the environment variable HOME does
not exist on windows. At least I have never seen it. I think it does
exist inside CYGWIN (perhaps in mingw also?) might the use of the HOME
variable be related to the Cygwin port?

The standard env variables relevant to this conversation are the two I
mentioned before (HOMEDRIVE, HOMEPATH) and the one mentioned above
(USERPROFILE) which seems to be equivalent to HOMEDRIVE and HOMEPATH
concatenated together.

Matthew

Tom Lane wrote:

I wrote:

win32 hackers, anyone know why it's like this?

Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.

I think what happened is that SSL was known to be broken on Win32 and
someone submitted a patch and I thought it now worked, but obviously it
doesn't. Perhaps the fix was just so it compiled with SSL.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073