[BUGS] BUG #6312: Test bug
The following bug has been logged on the website: Bug reference: 6312 Logged by: Magnus hagander Email address: mag...@hagander.net PostgreSQL version: Unsupported/Unknown Operating system: Linux Description: This is a test bug report. It seems bug reporting got broken on the new website - this bug is only to make sure it works now. So if this shows up on the list, it means bug reporting works... -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7640: Testing bug reporting form
The following bug has been logged on the website: Bug reference: 7640 Logged by: Magnus Hagander Email address: mag...@hagander.net PostgreSQL version: 9.2.1 Operating system: Web Description: This is just a test to make sure that the bug reporting form has been unbroken by the latest commits. Please don't respond to it - I will figure it out from my own mailbox that it works... And sorry for the noise.. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4322: Problems with field not updatable
Alexandre Caneo wrote:
> The following bug has been logged online:
>
> Bug reference: 4322
> Logged by: Alexandre Caneo
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.6
> Operating system: WIN XP
> Description:Problems with field not updatable
> Details:
>
> I'm using Win XP SP2, VB6 and PostgreSql 8.2.6.
>
> When I select the datas with this instruction
> "select a.x from a,b where a.z = b.z order by 1"
> the program run very well and I can insert, update and delete rows. But,
> when I select any column from table b an error occurs when I try to modify
> the column value from textbox for an example.
> "Binding Collection Error. field not updatable".
>
> String connection
> ls_StrConn = "PROVIDER=MSDASQL.1; DRIVER={PostgreSQL UNICODE};
> DATABASE=" & ls_Conexao & "; SERVER=" & ls_Host & "; PORT=" & ls_Servico &
> "; UID=" & ls_login & "; PWD=" & ls_Senha & "; ByteaAsLongVarBinary=1;"
>
> Recordset's properties
> mo_Record.CursorType = adOpenDynamic
> mo_Record.LockType = adLockOptimistic
>
> mo_Record.Open mo_Command
>
> One more thing.
> I don't need update the table's b column, just show them.
If you don't need updating, you should open your cursor as either
adOpenStatic or adOpenForwardOnly. Using adOpenDynamic explicitly
requests the ability to do updates/inserts/deletes through the cursor.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: RES: [BUGS] BUG #4322: Problems with field not updatable
Can't say that I do. I think you need to get the ODBC folks to look at
it, the problem appears to be there rather than in the server product.
//Magnus
Alexandre Caneo wrote:
> Magnus,
>
> I've tried open cursor with adOpenStatic or adOpenForwardOnly, but it didn't
> work.
>
> Do you have others suggestions?
>
> Tks.
> Alexandre.
>
>
> -Mensagem original-
> De: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Enviada em: segunda-feira, 28 de julho de 2008 08:34
> Para: Alexandre Caneo
> Cc: pgsql-bugs@postgresql.org
> Assunto: Re: [BUGS] BUG #4322: Problems with field not updatable
>
> Alexandre Caneo wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 4322
>> Logged by: Alexandre Caneo
>> Email address: [EMAIL PROTECTED]
>> PostgreSQL version: 8.2.6
>> Operating system: WIN XP
>> Description:Problems with field not updatable
>> Details:
>>
>> I'm using Win XP SP2, VB6 and PostgreSql 8.2.6.
>>
>> When I select the datas with this instruction
>> "select a.x from a,b where a.z = b.z order by 1"
>> the program run very well and I can insert, update and delete rows. But,
>> when I select any column from table b an error occurs when I try to modify
>> the column value from textbox for an example.
>> "Binding Collection Error. field not updatable".
>>
>> String connection
>> ls_StrConn = "PROVIDER=MSDASQL.1; DRIVER={PostgreSQL UNICODE};
>> DATABASE=" & ls_Conexao & "; SERVER=" & ls_Host & "; PORT=" & ls_Servico &
>> "; UID=" & ls_login & "; PWD=" & ls_Senha & "; ByteaAsLongVarBinary=1;"
>>
>> Recordset's properties
>> mo_Record.CursorType = adOpenDynamic
>> mo_Record.LockType = adLockOptimistic
>>
>> mo_Record.Open mo_Command
>>
>> One more thing.
>> I don't need update the table's b column, just show them.
>
> If you don't need updating, you should open your cursor as either
> adOpenStatic or adOpenForwardOnly. Using adOpenDynamic explicitly
> requests the ability to do updates/inserts/deletes through the cursor.
>
> //Magnus
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.441 / Virus Database: 270.5.6/1523 - Release Date: 25/7/2008
> 00:00
>
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.441 / Virus Database: 270.5.6/1523 - Release Date: 25/7/2008
> 00:00
>
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4337: psql -c case insensitive
Tom Lane wrote: > "none" <[EMAIL PROTECTED]> writes: >> I'm programming an application that uses psql (...) -c "ALTER DATABASE >> \"MyBase\" RENAME TO \"MyBase2\" and it doesn't work because it looks for a >> "mybase" database name. > > Works for me. I speculate that your scripting language is losing the > embedded double-quotes somewhere before psql gets them. I don't know > much about Windows scripting so it's hard to say more than that; but > an extra interpretation pass over the command string would probably > cause such a problem. Most likely you're bit by the completely insane rules of quoting in the windows commandshell. See for example the comments around it in src/port.h in the PostgreSQL distribution. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Bruce Momjian wrote: > Tom Lane wrote: >> Magnus Hagander <[EMAIL PROTECTED]> writes: >>> Thomas H. wrote: >>>> so at least that explains the "changed" behaviour. nevertheless, >>>> LC_MESSAGES seems to be defunct - with the "locale" folder present, >>>> pg always picks the os' language and ignores the lc_message value. >>> This looks like I can reproduce though, at least on cvs head. Did this >>> work for you in previous versions? >> Maybe we were using a different build of gettext in the previous >> releases, one that didn't look at the same info as the current code? >> >> Anyway the patch mentioned at the start of the thread >> http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php >> purports to fix this. It doesn't seem to have gotten reviewed >> though. > > Agreed. Magnus, someone, can we get feedback on the patch at this URL? > > http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php IIRC, there was further work to be done on the patch before it was to be applied, and we held off the review until then. Gevik - can you comment on this? Where are we, what needs ot be done still? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Dan Kaminsky wrote: > > > Tom Lane wrote: >> Dan Kaminsky <[EMAIL PROTECTED]> writes: >> >>> My question has been: When you attempt to create an SSL connection >>> to database.backend.com, do you actually validate that: >>> >> >> >>> 1) The subject name of the certificate you're connecting to is >>> database.backend.com, and >>> 2) At least the basic checks (expiration, chaining back to a valid >>> root) occur? >>> >> >> [ shrug... ] We do whatever OpenSSL's default validation behavior is. >> If that's inadequate you probably ought to be taking it up with them, >> instead of trying to get downstream projects to fix it one at a time. >> >> regards, tom lane >> > Heh, you're the one making guarantees to your users. I'm just asking > the exact nature of those guarantees. I agree that #2 is entirely under > the control of OpenSSL -- but I'd like to know if #1 is being satisfied, > i.e. OpenSSL knows you're looking to validate database.backend.com as > opposed to "some cert that chains back", which is a worthless security > assertion. We do not validate the name. It is stated in a comment at the top of f-secure.h that we do, but the code is all behind #ifdef NOT_USED. It would probably not be a bad idea to have that check enabled by default, but a way to turn it off. (I don't believe OpenSSL does this verification either, because AFAICS OpenSSL only ever sees the IP address of the server, and not the FQDN) We do, however, return the peer certificate information to the libpq client, that can verify this if it's considered necessary by the *application*. That said, claiming that the check of the chain up to a root certificate is wortheless is very far from correct. Used the proper way, and the way I most often see it deployed with PostgreSQL, makes it very worthy. Because people normally either bundle the server certificate itself with the application, in which case it will only ever connect to that server (self-signed cert). Or they have a dedicated CA for this purpose. Is it perfect? Far from. But it's certainly not worthless. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> (I don't believe OpenSSL does this verification either, because AFAICS >> OpenSSL only ever sees the IP address of the server, and not the FQDN) > > In common usages libpq doesn't have the FQDN of the server either. > To impose such a requirement, we'd have to forbid naming the server > by IP address or via a domain-search-path abbreviation. You could issue a certificate to an IP address, so you could match the textual representation of the IP in that case. Or you could require the FQDN for a SSL connection when this verification is enabled. A similar restriction already exists for Kerberos, for example. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Dan Kaminsky wrote: > > > Tom Lane wrote: >> Magnus Hagander <[EMAIL PROTECTED]> writes: >> >>> (I don't believe OpenSSL does this verification either, because AFAICS >>> OpenSSL only ever sees the IP address of the server, and not the FQDN) >>> >> >> In common usages libpq doesn't have the FQDN of the server either. >> To impose such a requirement, we'd have to forbid naming the server >> by IP address or via a domain-search-path abbreviation. >> >> regards, tom lane >> > Well, right now, SSL does nothing for you, so you have to do something. > It's OK, SSL isn't doing a lot for a lot of people, but this is the > beginning of us calling people out on that. Do feel free to explain how it "does nothing" for you with properly set up certificates (see my previous email). (I'm still not saying it cannot be significantly improved, of course) > You can handle IP address and domain-search-path by having an option for > explicitly declaring the subject name to be expected at the other side > of the SSL connection. In other words, sever the DNS/FQDN link, and > just explicitly say "however I reach that host over there, I expect > database.backend.com". You can do this today. If you are willing to do it in the application, just verify the certificate DN and you're done. Yes, it would certainly be a lot better to do the validation earlier in the chain (if you're sending plaintext password, you'll end up sending the password before you do the validation. But I don't think you even can do that in current versions), and if it was slightly easier to do, but you can certainly validate the cert if you want to. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Dan Kaminsky wrote: > >>> Well, right now, SSL does nothing for you, so you have to do >>> something. It's OK, SSL isn't doing a lot for a lot of people, but >>> this is the >>> beginning of us calling people out on that. >>> >> >> Do feel free to explain how it "does nothing" for you with properly set >> up certificates (see my previous email). (I'm still not saying it cannot >> be significantly improved, of course) >> >> > If the only roots set up are private roots, it works great. > > If there are generic roots (Verisign etc), or if no roots are checked at > all, it's useless. > > Pretty simple Good, then we're in agreement that far. (FWIW, I don't think I've ever seen a PostgreSQL server with a certificate off a global root. I've seen plenty off a corporate root though, which could in theory have similar issues - but at least you're in control of your own problem in that case) >>> You can handle IP address and domain-search-path by having an option for >>> explicitly declaring the subject name to be expected at the other side >>> of the SSL connection. In other words, sever the DNS/FQDN link, and >>> just explicitly say "however I reach that host over there, I expect >>> database.backend.com". >>> >> >> You can do this today. If you are willing to do it in the application, >> just verify the certificate DN and you're done. >> >> Yes, it would certainly be a lot better to do the validation earlier in >> the chain (if you're sending plaintext password, you'll end up sending >> the password before you do the validation. But I don't think you even >> can do that in current versions), and if it was slightly easier to do, >> but you can certainly validate the cert if you want to. >> >> //Magnus >> > See, I don't care *why* things are broken -- whether they're broken at > the application, at libpq, or at openssl, I'm asking the direct question > -- is SSL doing anything in common deployment, and if not, what needs to > be done to fix that? > > Background: After the DNS flaw was found, I started looking around to > see if SSL was a legitimate protection. Everywhere I looked, I found > issues. It's pretty embarrassing to find out that even SSL VPN's aren't > checking certs. So, yeah, I'm looking to see what level of protection > is out there. > > So, not caring *why* things are broken -- is it fair to say that libpq's > use of SSL didn't defend against the DNS bug, in any scenario except > where custom roots were set up? Yes, I think that's fair. You *can* do the verification yourself, but libpq will not do it for you. Only I will claim that the common deployment, as you refer to above, *is* with a custom root. PostgreSQL server are *very* seldom "published to the internet", and therefor tend not to use the global CA roots. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Dan Kaminsky wrote: > >> Good, then we're in agreement that far. >> >> > Cool! >> (FWIW, I don't think I've ever seen a PostgreSQL server with a >> certificate off a global root. I've seen plenty off a corporate root >> though, which could in theory have similar issues - but at least you're >> in control of your own problem in that case) >> > OK, now describe client behavior for me. Is the average client > configured to accept: > > 1) No roots (but still works for some unknown reason) > 2) Explicitly configured corporate roots > 3) Explicitly configured corporate roots, AND global roots > 4) Global roots (but still works for some unknown reason) > > Keep in mind that at least Debian distributes a ca-certificates package, > and I can't imagine they're alone. My guess is you'll find both options 1 and 2 fairly often, and 3 and 4 very seldom. (Note that if you configure libpq for no roots, it will accept any certificate without verifying the chain) Unless, that is, some distribution (like debian) changes the default config there. I don't know enough about the specific distros to really comment on that. >> Yes, I think that's fair. You *can* do the verification yourself, but >> libpq will not do it for you. >> >> Only I will claim that the common deployment, as you refer to above, >> *is* with a custom root. PostgreSQL server are *very* seldom "published >> to the internet", and therefor tend not to use the global CA roots. >> > So one of the nastier aspects of the DNS bug is that internal > communication may get routed out to the Internet, because it's DNS that > keeps things behind the firewall. If SSL is being used, the > *presumption* is that there's a MITM we want to defend against. That's one of the things, yeah, agreed. I meant the internals part only as an argument for why you'll see most pg deployments not using global certs. OTOH, if your firewall lets your clients (or even worse - your webserver or so) connect out to arbitrary machines on the PostgreSQL port, it can easily be argued that you have a lot of homework to do elsewhere as well ;-) But that's just a mitigating factor, and not a solution. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Peter Eisentraut wrote: > Dan Kaminsky wrote: >>>> 1) No roots (but still works for some unknown reason) >>>> 2) Explicitly configured corporate roots >>>> 3) Explicitly configured corporate roots, AND global roots >>>> 4) Global roots (but still works for some unknown reason) > >> So, if you do nothing special, it's #1? Sounds like the path of least >> resistance is no security. Uh oh. > > Yeah, in the average, if not common case, a user interested in SSL use would > probably just follow the recipe in the documentation for creating and > installing a self-signed certificate with no certificate checking in the > client. Which, as you correctly observe, is pretty much completely useless. > > Someone should probably redesign, reconfigure, and redocument this. Agreed. I'd like to suggest that for the "easy fix" (without supporting custom callbacks and whatever) we create a new connection parameter called "sslverifypeer". It can be set to "verifypeer", "verifycert" or "off". When set to "verifypeer", we will verify the peer name and the certificate. When "verifycert" we just verify the certificate, fail if we can't find a root certificate, but ignore the common name. "off" should be self-explaining. I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with a default of "off". That way we don't break existing setups, but give users the ability to verify if if they want to. Comments? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with >> a default of "off". That way we don't break existing setups, but give >> users the ability to verify if if they want to. > > This seems a bit large/invasive/new-feature-ish for a backpatch. I agree in principle, but I really didn't want to leave our "old" users in the cold, unable to actually use SSL to secure their systems.. The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* time ago, and the commit message just says "silence compiler warnings", so I've not managed to figure out why... //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* >> time ago, and the commit message just says "silence compiler warnings", >> so I've not managed to figure out why... > > I think the commit you're looking for is this one: > > 2002-09-26 00:41 momjian > > * doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c, > src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth > client-side certificate infrastructure. > > so you'd probably need to root around in the archives from around then > to see why this was considered a good idea. No, that's not the one. It's the one after that one, at: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c.diff?r1=1.14;r2=1.15 In general, that code needs a look-over, I think. There may be more changes required. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> I think the commit you're looking for is this one: >>> 2002-09-26 00:41 momjian > >> No, that's not the one. It's the one after that one, at: > > No, that one is just fallout from having removed the *use* of the > function in the earlier patch. Hmm. Bummer, that's right. Anyway. The code should be fairly usable I think, but we'll see that once there is some code to test... If the method I suggested seems good I'll work along that line, and we'll see when it's done if it's reasonable to backpatch it or not. If it seems the wrong track, I'm interested in suggestions on which direction we should be going in :-) //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgresql v8.3.3 + Perl v5.10
Peter Eisentraut wrote: > [EMAIL PROTECTED] wrote: >> 1. Install Perl v5.10 >> 2. Install PG >> 3. PG does not see that machine has Perl >> 4. Remove Perl and PG >> 5. Instll Perl v5.8 >> 6. Install PG >> 7. PG work fine >> Problem is that PG does not recognize Perl v5.10 =( > > Please provide the actual commands and the actual output, not abstract > descriptions. > > I can tell you that I am building and running PostgreSQL and Perl 5.10 just > fine. So the problem must be in the details, which are not evident from your > description. I think he is talking about the Windows binary distribution. In which case, the answer is no - the binary windows distribution of 8.3 does *not* work with perl 5.10. Other platforms, and build-from-source on Windows should, AFAIK. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4379: failt to get system metrics fot terminal services : 87
andre kallmeyer wrote: > The following bug has been logged online: > > Bug reference: 4379 > Logged by: andre kallmeyer > Email address: [EMAIL PROTECTED] > PostgreSQL version: PostgreSQL 8.0 > Operating system: windows xp > Description:failt to get system metrics fot terminal services : 87 > Details: > > I can not install the Programm. PostgreSQL 8.0 is no longer supported on Windows. You need to be using 8.2 or 8.3 (8.3 is really the recommended choice here) //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] win32 installer page in pgfoundry is wrong
Alvaro Herrera wrote: > Hi, > > There is an announcement at http://pgfoundry.org/projects/pginstaller/ > titled > Don't look here for announcements > which contains an URL: > http://www.postgresql.org/ftp/win32 > > This URL returns a 404. Um, yeah, who removed that symlink? And why? If there was a good reason, we should change the links into it. If it was done by mistake, the symlink should just be put back :-) //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [pgsql-www] [BUGS] win32 installer page in pgfoundry is wrong
Dave Page wrote:
> On Thu, Aug 28, 2008 at 8:30 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> Alvaro Herrera wrote:
>>> Hi,
>>>
>>> There is an announcement at http://pgfoundry.org/projects/pginstaller/
>>> titled
>>> Don't look here for announcements
>>> which contains an URL:
>>> http://www.postgresql.org/ftp/win32
>>>
>>> This URL returns a 404.
>> Um, yeah, who removed that symlink? And why? If there was a good reason,
>> we should change the links into it. If it was done by mistake, the
>> symlink should just be put back :-)
>
> It was removed a while back as it was only ever supposed to be a
> temporary measure to help the new windows users when we released 8.0
> ('cos apparently some people thought they wouldn't be able to navigate
> the FTP site with the same effectiveness as *nix users).
Ok. link updated.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4393: failed toget system metics for terminal services:87
Tom Lane wrote: > Russell Smith <[EMAIL PROTECTED]> writes: >> Hemavathi B N wrote: >>> PostgreSQL version: 8.0 >>> Operating system: windows 2003 >>> Description:failed toget system metics for terminal services:87 > >> My guess is that you are not installing from the console, but are using >> terminal services. I don't think you can install from a terminal >> services connection. Try installing directly from the console. > > Also try a newer Postgres release, per the identical bug report posted > less than a week ago: > http://archives.postgresql.org/pgsql-bugs/2008-08/msg00241.php > I believe this is something that's fixed as of 8.2. Yes, IIRC that whole codepath has been rewritten. And 8.0 isn't supported anymore (on windows), so you really sholdn't be installing that on a new system :P //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Heikki Linnakangas wrote: > ITAGAKI Takahiro wrote: >> Tom Lane <[EMAIL PROTECTED]> wrote: >> >>> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: >>>> We probably need to add PG_BINARY when we open control files >>>> because 0x1A is an end-of-file marker on Windows. >>> Well, why is that a bug? If the platform is so silly as to define text >>> files that way, who are we to argue? >> >> Google says it is for for backward compatibility with CP/M >> http://en.wikipedia.org/wiki/End-of-file >> and adding O_BINARY is the answer. >> >> http://codenewbie.com/forum/standard-c-c/1208-binary-i-o-file-reading-0x1a-trouble.html >> > > Yes, apparently that's exactly why we have PG_BINARY, see c.h: > >> /* >> *NOTE: this is also used for opening text files. >> *WIN32 treats Control-Z as EOF in files opened in text mode. >> *Therefore, we open files in binary mode on Win32 so we can read >> *literal control-Z.The other affect is that we see CRLF, but >> *that is OK because we can already handle those cleanly. >> */ >> #if defined(WIN32) || defined(__CYGWIN__) >> #define PG_BINARYO_BINARY >> #define PG_BINARY_A "ab" >> #define PG_BINARY_R "rb" >> #define PG_BINARY_W "wb" >> #else >> #define PG_BINARY0 >> #define PG_BINARY_A "a" >> #define PG_BINARY_R "r" >> #define PG_BINARY_W "w" >> #endif > > I don't see anything wrong with the patch, but I wonder if there's more > open() calls that need the same treatment? Like the one in > pg_resetxlog.c/ReadControlFile(). Agreed, and I think that one would also need it - and pg_resetxlog already does this when it writes the file. A quick look doesn't show any other places, but I may have missed some? /Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Magnus Hagander wrote: > Heikki Linnakangas wrote: >> ITAGAKI Takahiro wrote: >>> Tom Lane <[EMAIL PROTECTED]> wrote: >>> >>>> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: >>>>> We probably need to add PG_BINARY when we open control files >>>>> because 0x1A is an end-of-file marker on Windows. >>>> Well, why is that a bug? If the platform is so silly as to define text >>>> files that way, who are we to argue? >>> Google says it is for for backward compatibility with CP/M >>> http://en.wikipedia.org/wiki/End-of-file >>> and adding O_BINARY is the answer. >>> >>> http://codenewbie.com/forum/standard-c-c/1208-binary-i-o-file-reading-0x1a-trouble.html >>> >> Yes, apparently that's exactly why we have PG_BINARY, see c.h: >> >>> /* >>> *NOTE: this is also used for opening text files. >>> *WIN32 treats Control-Z as EOF in files opened in text mode. >>> *Therefore, we open files in binary mode on Win32 so we can read >>> *literal control-Z.The other affect is that we see CRLF, but >>> *that is OK because we can already handle those cleanly. >>> */ >>> #if defined(WIN32) || defined(__CYGWIN__) >>> #define PG_BINARYO_BINARY >>> #define PG_BINARY_A "ab" >>> #define PG_BINARY_R "rb" >>> #define PG_BINARY_W "wb" >>> #else >>> #define PG_BINARY0 >>> #define PG_BINARY_A "a" >>> #define PG_BINARY_R "r" >>> #define PG_BINARY_W "w" >>> #endif >> I don't see anything wrong with the patch, but I wonder if there's more >> open() calls that need the same treatment? Like the one in >> pg_resetxlog.c/ReadControlFile(). > > Agreed, and I think that one would also need it - and pg_resetxlog > already does this when it writes the file. A quick look doesn't show any > other places, but I may have missed some? I had a chat with Heikki about this, and the proper way to fix it. Should there actually be any reason not to *always* open our files with O_BINARY? That seems to be what should mimic what Unix does, which would be what we expect, no? If that is so, then I propose we do that for 8.4, and just backpatch the O_BINARY flag to these two locations for 8.3 and 8.2. Thoughts? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Andrew Dunstan wrote: > > > Magnus Hagander wrote: >> I had a chat with Heikki about this, and the proper way to fix it. >> >> Should there actually be any reason not to *always* open our files with >> O_BINARY? That seems to be what should mimic what Unix does, which would >> be what we expect, no? >> >> If that is so, then I propose we do that for 8.4, and just backpatch the >> O_BINARY flag to these two locations for 8.3 and 8.2. Thoughts? >> >> >> > > ISTR there are a few places where we want CRLF translation (config files?) These seem to be using fopen() (through AllocateFile()), which wouldn't be affected by this. > I'd be fairly conservative about making changes like this. This is why my proposal would be not to backpatch such a change, but to only do it for 8.4. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Andrew Dunstan wrote: > > > Tom Lane wrote: >> Bruce Momjian <[EMAIL PROTECTED]> writes: >> >>> Tom Lane wrote: >>> >>>> Well, why is that a bug? If the platform is so silly as to define text >>>> files that way, who are we to argue? >>>> >> >> >>> The problem is that our pg_controldata might have binary values that >>> contain 0x1a that will be confused by the operating system as >>> end-of-file. >>> >> >> pg_controldata is certainly already being read as binary. > > Umm, no, it is in the backend I believe but not in the utilities. Hence > the original bug report. We need to add the binary flag in > pg_controldata.c and pg_resetxlog.c. Right. I'll go ahead and put that part in (I find two locations - the one in the original patch, and the extra one Heikki noticed). >> The >> discussion here is about *text* files, particularly configuration >> files. Why should we not adhere to the platform standard about >> what a text file is? >> >> If you need a positive reason why this might be a bad idea, consider the >> idea that someone is examining postgresql.conf with a text editor that >> stops reading at control-Z. He might not be able to see items that the >> postmaster is treating as valid. >> >> >> > > Yes, exactly right. We certainly can't just open everything in binary > mode. Magnus did say that all the current config files are opened in > text mode as far as he could see. The point being that the config files are opened with AllocateFile(), which in turn calls fopen(). It doesn't use open(). The proposal was only to make all *open()* calls do it binary. I was under the impression that on Unix, that's what open() did, so we should behave the same? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Magnus Hagander wrote: > Andrew Dunstan wrote: >> >> Tom Lane wrote: >>> Bruce Momjian <[EMAIL PROTECTED]> writes: >>> >>>> Tom Lane wrote: >>>> >>>>> Well, why is that a bug? If the platform is so silly as to define text >>>>> files that way, who are we to argue? >>>>> >>> >>>> The problem is that our pg_controldata might have binary values that >>>> contain 0x1a that will be confused by the operating system as >>>> end-of-file. >>>> >>> pg_controldata is certainly already being read as binary. >> Umm, no, it is in the backend I believe but not in the utilities. Hence >> the original bug report. We need to add the binary flag in >> pg_controldata.c and pg_resetxlog.c. > > Right. > I'll go ahead and put that part in (I find two locations - the one in > the original patch, and the extra one Heikki noticed). Eh, both were in the original patch, I just didn't scroll far enough :-) Applied to HEAD and backpatched back to 8.2 - since it only affects Windows, we don't go further. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Andrew Dunstan wrote: > > > Tom Lane wrote: >>> The point being that the config files are opened with AllocateFile(), >>> which in turn calls fopen(). It doesn't use open(). The proposal was >>> only to make all *open()* calls do it binary. I was under the impression >>> that on Unix, that's what open() did, so we should behave the same? >>> >> >> That seems just weird. I do not think there's any correlation between >> whether we use open or fopen and whether the file is text or binary. >> Even if it happens to be true right now, depending on it would be >> fragile. >> >> >> > > I agree. If you really want something like that you should invent > OpenConfigFile() or some such. But it hardly seems worth it. Well, the AllocateFile() API already has the ability to specify if it's a text file or not (using the fopen syntax). And given that we have a way to specify it for open (PG_BINARY), we can just leave it that way I guess. Even if we end up always specifying PG_BINARY, that may keep things less fragile. As long as we remember to specify it. (PG_BINARY is a no-op on all other platforms than Windows, btw, because there is no way to specify anything other than binary mode for open() on Unix) //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4410: Indexes not seen right away
Greg Sabino Mullane wrote: > >>>> Does it have pg_index.indcheckxmin = true? If so, see README.HOT. >>> Yes, that was probably it. Is this worth noting in the documentation >>> somewhere >>> (other than the technical bowels of HOT)? Perhaps in the CREATE INDEX >>> docs? > ... >> I have attached the scripts I used for testing. I don't think it is >> worth documenting this until we have 8.4 released and people start using >> it. > > I'm not following this, Bruce. HOT came out in 8.3, not 8.4, so why would we > wait on documenting the problem? > >> I believe a mention in the manual would require quite complex wording. > > Seems something would be better than nothing. Example: > > "Note: In versions 8.3 and higher, indexes may not be immediately visible > due to the way HOT chains work. For more information, please see > ." I think putting links in the user documentation directly to development README files that require you to look in the source code is a bad thing... > It might be nice to upgrade README.HOT to a real documentation page > as well. If we want the full explanation there, that's how it should be done :-) //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4451: initcap() function capitalizes incorrectly
Scott V wrote: > The following bug has been logged online: > > Bug reference: 4451 > Logged by: Scott V > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.1 > Operating system: Mac OS X 10.5.4 > Description:initcap() function capitalizes incorrectly > Details: > > initcap() capitalizes incorrectly when passing strings containing certain > two-byte UTF-8 characters. E.g., when argument = 'mātūrāte', initcap > returns 'MāTūRāTe'. Correct result should be 'Mātūrāte'. > > The function appears to be incorrectly interpreting the two-byte chars as > non-alphamueric characters. They are in fact alphanumerics, they just have > diacritical markings. What's your setting for lc_collate? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4447: install failed to start; libintl3.dll was not found
Jen McCann wrote: > The following bug has been logged online: > > Bug reference: 4447 > Logged by: Jen McCann > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.4 > Operating system: Win2k3 server sp1 > Description:install failed to start; libintl3.dll was not found > Details: > > I have attempted to install postgreSQL 8.3.4. on my win2k3 server sp1 > (enterprise edition) machine, and it has failed with the following error: > > initdb.exe - Unable to Locate Component > this application has failed to start because libintl3.dll was not found. > Re-installing the application max fix this problem. > > Note: the libintl3.dll was indeed present on in the PostgreSQL 8.3\bin > folder. > > I have been able to install version 8.2 without issue. > However, the same issue was observed when attempting to install v8.3.3 Strange. You are using the MSI installer from our ftp site? Or are you using the binaries-no-installer? Also, please verify using "depends.exe" that all the DLL files that libintl3.dll requires are also present. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4455: Valid SSL certificate reported as expired
Andrej Podzimek wrote: > The following bug has been logged online: > > Bug reference: 4455 > Logged by: Andrej Podzimek > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.3 > Operating system: Linux 2.6.26.5 > Description:Valid SSL certificate reported as expired > Details: > > Hello, > > both psql and pgAdmin refuse to connect to my server using SSL, with this > inexplicable error message: > > Error connecting to the server: SSL error: sslv3 alert certificate > expired > > CA certificate is valid till 2011. > Server certificate is valid till 2009. > Client certificate is valid till 2009. > > So the error message is obviously a nonsense. Any chance this is a debian based distribution, and that the certificate may be using a key that they have blacklisted due to the random number problem? It may be that OpenSSL gives an incorrect error message in this case... If not, please try with the OpenSSL s_client/s_server applications with the same certificates and see if it works there. Also, check if there may be some kind of date issue with the CRL. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4572: Incorrect error message when using wrong password with hostssl
Tommy Gildseth wrote: > The following bug has been logged online: > > Bug reference: 4572 > Logged by: Tommy Gildseth > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.x,8.2.x > Operating system: Linux > Description:Incorrect error message when using wrong password with > hostssl > Details: > > When logging into postgresql requiring SSL, providing the wrong password > will produce an incorrect and confusing error message. Hi! This has been fixed for 8.4. It will now show: psql: FATAL: password authentication failed for user "foo" FATAL: no pg_hba.conf entry for host "127.0.0.1", user "foo", database "postgres", SSL off This indicates that you had a password failure, and then retried with SSL off. For now, and if you later want to get rid of the second message, connect with PGSSLMODE=require (or put sslmode=require in the connection string) - that way you will prevent the attempt to reconnect without SSL. We can't easily backpatch this since it may break existing applications that aren't equipped to deal with multiline errors. //Magnus > == pg_hba.conf === > hostssl all postgres 192.168.123.234 255.255.255.255 md5 > == > > == Logging in: === > [EMAIL PROTECTED] ~]$ psql -W -h pgtest02 > Password: > psql: FATAL: no pg_hba.conf entry for host "192.168.123.234", user > "postgres", database "postgres", SSL off > == > > The error message returned here is clearly bogus. It's correct in that there > is no pg_hba.conf entry for that user/host, with SSL off, but imo. it should > have returned the more usefull error message: > == > psql -W -h pgtest02 > Password: > psql: FATAL: password authentication failed for user "postgres" > == > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4618: nolock changes first column name of query result set to 'nolock'
brian wrote: > The following bug has been logged online: > > Bug reference: 4618 > Logged by: brian > Email address: b4kra...@yahoo.com > PostgreSQL version: 8.3.5 build1400 > Operating system: windows xp > Description:nolock changes first column name of query result set to > 'nolock' > Details: > > query1 works fine, first column in table is called movieid1: > select * from netflix.ratings where movieid = 1 > > > > > query2 is a bug and should work just fine, but gives error: > ERROR: column "movieid" does not exist > LINE 2: select * from netflix.ratings with (nolock) where movieid = ... I don't know where you got "with (nolock)" from, but that's not PostgreSQL syntax - and AFAIK it's not standard SQL at all. Just remove it and you should be fine. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_listener entries deleted under heavy NOTIFY load only on Windows
Marshall, Steve wrote: > Any thoughts on whether or not this patch should be included in a future > PostgreSQL release? If so, any thoughts on additional testing, etc, > that needs to be done? Should the patch be added to a minor release of > 8.3, or only included forward in 8.4? In my opinion, this is a pretty > serious error causing some major problems and workarounds in systems I > am working on, should I would vote for inclusion in minor releases. > > The post below seems to have become disassociated from the rest of the > thread on this bug, perhaps because it was issued in February, and the > rest of the thread was posted in January. Is there any way to make the > mailing list archives link these messages back to the rest of the > thread? Hi! Sorry, I've been unable to track this thread properly as it happened tue to travelling, but I've tried to read back through it now. What's the timing of the errors? Is there a chance that we are sending the kill signal before the signal handling thread has actually started *and created the named pipe*? We set up the signal handling stuff pretty early, but we do seem to let the postmaster continue it's work before it's up... Going back to your tests, did it ever require more than one retry? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_listener entries deleted under heavy NOTIFY load only on Windows
Marshall, Steve wrote: > What's the timing of the errors? Is there a chance that we are sending > the kill signal before the signal handling thread has actually started > *and created the named pipe*? > > We set up the signal handling stuff pretty early, but we do seem to let > the postmaster continue it's work before it's up... > > Under heavy load, a signal will typically be dropped within the first > few minutes. However, it can sometimes take a little while before the > problem happens. Thousands of the same signal to the same process may > be properly handled before one is mishandled. This is not consistant > with a problem with initial creation of the pipe. > > Going back to your tests, did it ever require more than one retry? > > Yes, but rarely. In a 90 hour stress test with code that allowed up to 5 > calls to CallNamedPipe, I found 760 signals that required a retry. Only > one required two retries. That is why I set the number of retries to 2. > The behavior might be different if the sleep interval between retries > was changed. I used a 20 ms sleep interval between retries in all my > tests, and in the patch I sent. I have applied a modified version (no functional changes, just stylistic) of this patch to head and backpatched to 8.2 which is as far back as we support win32. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4694: uppercase path cause postgres can't start
trainee wrote: > The following bug has been logged online: > > Bug reference: 4694 > Logged by: trainee > Email address: traine...@163.com > PostgreSQL version: 8.3.6 > Operating system: windows xp > Description:uppercase path cause postgres can't start > Details: > > I download zip binaray 8.3.6 > extract into e:\postgres > > set system variables "path" add "E:\POSTGRES\PGSQL\BIN;" --uppercase > > cmd; > > pg_ctl register -N postgres -D "e:\postgres\pgdata" > > when I start server , failure > > error msg is : > > LOG: could not open directory "/share/timezone": No such file or directory > FATAL: could not select a suitable default timezone > DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL > does not support leap seconds. > > if I change system variables "path" into lowercase, success. > > why? The path has to have the same case as the directory name in the filesystem. This is due to the fact that NTFS is case-insensitive but case-preserving. The recommendation is to always include the full path to the pg_ctl command when you register the service. That said, I have applied a patch that makes the check that fails case insensitive, which should fix the most common cases of this happening. It will be included in the next version (in both 8.2/8.3 and in the upcoming 8.4) //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Martin Pitt writes: >> I do see the benefit of failing to connect to an SSL-enabled server >> *if* I have a root.crt which doesn't match. But why fail if I don't >> have one? > > I think I agree with Martin on this. The server doesn't fail if you > don't provide it a root cert; it just doesn't try to trace client certs > to the root. It is not apparent why the client should be stricter than > that, and definitely not apparent why such strictness should be the > default behavior. It's "secure by default". Without it, most people will *never* get protected by verifying the certificate because they will not manually copy root certificates there. And it would open up a big window for making a very simple mistake (file missing or wrong name) that would then silently disable SSL verification completely. Arguably it's a bug to silently install a snakeoil cert by default. But I realize that you have issues with backwards compatibility. How about changing it so it points PGSSLROOTCERT to a system wide location that holds the root.crt file? The user can then override this if proper verification of a real certificate is wanted. (you could also disable certificate verification by setting PGSSLVERIFY=none, but that seems like a much worse fix) //Mangus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Tom Lane wrote: >>> It is not apparent why the client should be stricter than >>> that, and definitely not apparent why such strictness should be the >>> default behavior. > >> It's "secure by default". > > In my experience ssh itself isn't this strict. Why should libpq be? > I think most users will see this as a bug, not as being secure. ssh prompts the user when this happens. We don't have a mechanism for prompting the user. IIRC when you run ssh in a mode where it can't prompt the user, it will refuse to connect, thus being just as strict as we are. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Tom Lane wrote: >>> In my experience ssh itself isn't this strict. Why should libpq be? > >> ssh prompts the user when this happens. We don't have a mechanism for >> prompting the user. > > In the first place, I have never seen such a prompt, despite the fact > that I use ssh constantly to connect to machines that I know do not have > properly signed certificates. If there is such a prompt, it isn't the > default behavior. In the second place, unconditionally failing isn't a > particularly nice emulation of a prompting behavior. *really*? Here's what I get as an example (after removing the trust): h...@mha-laptop:~/.ssh$ ssh cvs.postgresql.org The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be established. DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3. Are you sure you want to continue connecting (yes/no)? ^C Are you saying you're not getting that? I've got that (or similar) on every single platform I recall having used... ssh doesn't use certificates, actually, it uses known host keys. The difference being that with certificates you trust the root and thereby everything under it. For ssh, afaik, you need to trust each host individually. > Perhaps a suitable compromise is to have the failure message include > a hint about how to prevent the failure if you don't want it? That would definitely work for me. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Tom Lane wrote: >>> In the first place, I have never seen such a prompt, despite the fact >>> that I use ssh constantly to connect to machines that I know do not have >>> properly signed certificates. > >> *really*? Here's what I get as an example (after removing the trust): > >> h...@mha-laptop:~/.ssh$ ssh cvs.postgresql.org >> The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be >> established. >> DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3. >> Are you sure you want to continue connecting (yes/no)? ^C > > This simply tells you that the machine has a new key since last time you > talked to it. It doesn't have anything to do with whether the machine's > cert has been signed by anybody. It also doesn't prevent you from > operating without a root.crt file of your own. SSH doesn't have certificates. The trusted key is as close as you get. You can compare it to ssl with *only* self-signed-certificate. Where it prompts you to authenticate the fingerprint of said self-signed-certificate. They do it through a prompt. We do it through a file. But as long as you in pg only deal with self-signed certs, the outcome is pretty much the same. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Martin Pitt wrote: > Peter Eisentraut [2009-04-10 14:56 +0300]: >> I assume the server has the snakeoil certificate installed? In that case, >> it >> is correct that the client refuses to proceed, although the exact manner of >> breaking could perhaps be improved. > > Is it really refusing self-signed certificates? That would be strange. It treats self-signed certificates the same way it treats anything else. In the case of a self-signed one, the certificate and the CA certificate are the same. Thus, you have to copy the server certificate to the client. (This is, of course, not a security issue in itself, because you don't copy the *key* over. Just as a FYI to those who thought it would be :-P) > I had thought it checks whether the user has the server signing > certificate of the server installed on his client home directory > (which, BTW, seems like a strange place to default to, and thus keep > it). That has just been brought up from previous versions. Perhaps we need to have a system wide root store as well - then you could point that to whatever snakeoil store you have, and it would find the cert correctly? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote: > Martin Pitt wrote: >> I do see the benefit of failing to connect to an SSL-enabled server >> *if* I have a root.crt which doesn't match. But why fail if I don't >> have one? > > I have digested this thread, and have done two things: improved the > documentation and posted a patch to make the error message clearer. > > In terms of your suggestion about root.crt, I think sslverify != none > should error if it can't verify the server's certificate, whether the > root.crt file is there or not. If you are asking for sslverify, it > should do that or error, not ignore the setting if there is no root.crt > file. The only other approach would be to add an sslverify value of > 'try' that tries only if root.crt exists. Doesn't "try" make the whole check pretty pointless, and you can just set it to "none" then? The point is, you need to *know*. "try" makes no sense. If we want to be sure it never fails to connect, we disable security by default - setting sslverify to "none". For those who care about security, we document clearly how to enable it, and make it very clear that we ship with this part of the security system disabled by default. (shipping in this way, btw, will be considered a bug by anybody in the security community. But that's a different community than ours, and at least there's a builtin way to fix it) Inventing a switch that makes it more or less impossible to figure out if you are going to be secure or not makes no sense. When dealing with security, maybe is the same as no, and you have to *know*. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Bruce Momjian writes: >> In terms of your suggestion about root.crt, I think sslverify != none >> should error if it can't verify the server's certificate, whether the >> root.crt file is there or not. If you are asking for sslverify, it >> should do that or error, not ignore the setting if there is no root.crt >> file. > > Fair enough. > >> The only other approach would be to add an sslverify value of >> 'try' that tries only if root.crt exists. > > +1 for adding a "try" setting (though I'm not sure if I like that name > or not). I don't think that we actually have any choice in the matter. > By the end of beta, we *will* have such a setting; the only question > in my mind is whether it will be default or not. That depends on > exactly how nasty the villagers become ... The option is there already, it's called "none". That's what people are asking for - they don't care who they are connecting to, just that the traffic is encrypted (be it legitimate or hacked traffic, at least it's encrypted). It's just a matter of if it's default or not. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Bruce Momjian wrote: >>> The only other approach would be to add an sslverify value of >>> 'try' that tries only if root.crt exists. > >> Doesn't "try" make the whole check pretty pointless, and you can just >> set it to "none" then? > > Not at all. What it means is that you control whether to make the check > by putting the file there (or not). Which you have to do anyway, if you > want to make the check. Which means that every time I connect, I need to first to make sure that the file is there, and that the proper user has permissions to read the file, *before* I connect. > All that the current definition of the setting > is accomplishing is forcing people to fool with their environment variables, > which is a pain in the neck to varying degrees depending on platform. That, or un-breaking their environment. >> Inventing a switch that makes it more or less impossible to figure out >> if you are going to be secure or not makes no sense. When dealing with >> security, maybe is the same as no, and you have to *know*. > > I am of the opinion that sslverify should have these values: > > off = never verify > on = verify if root.crt is present (default behavior) > force = verify, failing if root.crt is not present > > and the people who actually want to be "sure they're secure" can set the > "force" value in their environment. Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and something like "maybe" or "external" or "file". I'd find it very bad if you can say "sslverify=on" and then *not* end up getting it because of some external factor. That needs to be clear in the naming of the value if we go down that path. Plus you somehow need to overload it with the cn vs certificate only part. The ability to not do full hostname verification has been specifically asked for. > This is not measurably different in effect from the fact that we have > sslmode defaulting to "prefer" rather than "require". If you want to be > "sure you're secure" you need the latter setting, but I don't believe > there is even remotely a consensus for making that the default. That's a whole mess in itself, really. Originally, we had SSL on or off. If you set it to on, it required SSL. If you set it to off, it wouldn't use SSL. "sslmode=prefer" honestly makes no sense - if I don't care if it ends up encrypted or not (which it means), then why not just run with SSL off and not have to deal with the overhead? > BTW, what in the world prompted us to use "cn" as an allowed value for > sslverify? It looks for all the world like a typo for "on". Eh, what would you call it? It enables verification of the cn field in the certificate. Another option I considered was "full", but someone said that was bad - can't recall if that was on-list or off ATM. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and >> something like "maybe" or "external" or "file". I'd find it very bad if >> you can say "sslverify=on" and then *not* end up getting it because of >> some external factor. That needs to be clear in the naming of the value >> if we go down that path. > > I guess you didn't think through the implications of the sslmode > comment, but: this is all merest self-delusion. If a hostile server is > trying to fool you, all he needs to do is configure his pg_hba.conf to > accept your connection in non-SSL mode, and your super duper > guaranteed-to-work ssl verification doesn't do a thing. > > So unless you think you can persuade us to change the default sslmode to > "require", you're wasting your time making the above argument. Huh? When I want a secure connection, I set sslmode=require. The same way I in a browser make sure I'm running with a https connection. When I have done this, I expect to have the security of the https protocol. Not just maybe half of it. I agree the default shouldn't be "require", because that requires the server to be configured wit hit. In the on/off scenario, the reasonable default would be "off". The same way that imho it would make more sense to have sslverify default to "off" than to "maybe". >>> BTW, what in the world prompted us to use "cn" as an allowed value for >>> sslverify? It looks for all the world like a typo for "on". > >> Eh, what would you call it? It enables verification of the cn field in >> the certificate. Another option I considered was "full", but someone >> said that was bad - can't recall if that was on-list or off ATM. > > I would call it "on", and put the hostname behavior control somewhere > else. Overloading a security-sensitive parameter's meaning isn't a > particularly safe design, eh? Especially with a value that people > can't even read correctly if their eyes are a bit bleary. How is that overloading it? It says how far you want to take the verification of the certificate. It's overloading if you try to squeeze in the "try" or "maybe" or whatever it'd be called setting, but not until then. That said, I'd not object at all to changing it to on, but keeping the ability to set it to "cert" as well - because that's a feature people asked for, and that makes sense to use. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Hiroshi Inoue wrote: > Magnus Hagander wrote: >> Bruce Momjian wrote: >>> Martin Pitt wrote: >>>> I do see the benefit of failing to connect to an SSL-enabled server >>>> *if* I have a root.crt which doesn't match. But why fail if I don't >>>> have one? >>> I have digested this thread, and have done two things: improved the >>> documentation and posted a patch to make the error message clearer. >>> >>> In terms of your suggestion about root.crt, I think sslverify != none >>> should error if it can't verify the server's certificate, whether the >>> root.crt file is there or not. If you are asking for sslverify, it >>> should do that or error, not ignore the setting if there is no root.crt >>> file. The only other approach would be to add an sslverify value of >>> 'try' that tries only if root.crt exists. >> >> Doesn't "try" make the whole check pretty pointless, and you can just >> set it to "none" then? > > Yes the snapshot psqlodbc driver already set sslverify to none and can't > change it though it may be differnet from the expected behavior. It was > not so easy to implement because sslverify parameter is illegal for <= > 8.3 libpq and the psqlodbc driver doesn't rely on environment variables > at all. Whatever the default is, if you can't change the value I'd say that makes the ODBC driver pretty darn broken. It would be equally broken if it was set to the default and it wasn't possible to change it. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote: > Bruce Momjian wrote: >> It would be nice if 'sslverify' mimicked 'sslmode', which has these >> values: >> >> disable >> allow >> prefer >> require >> >> I don't see how we could use 'allow', but 'disable', 'prefer', and >> 'require' seem to work for sslverify, like sslmode. > > OK, crazy idea --- we use the three-value mode for sslverify listed > above, but we have it default to the value of sslmode. So, when sslmode > is prefer (the default), sslverify is 'prefer'. When sslmode is > require, so is sslverify, and of course disable sets them both to > disable. This gives us good defaults (prefer), but auto-locks down the > system when sslmode is 'require'. This hides what the system does pretty darn well. sslverify=prefer - what does that mean? It's far from clear. Plus, I don't understand how the "verify certificate but not hostname" fits into this, but that could be because I really don't understand what they mean :-) However, slaving the default to sslmode probably make sense. As long as sslmode is not set to require, it doesn't make that much sense to verify the certificate at all, so I can see that defaulting to "none" or "off" or whatever in that case. I still think controlling it by an external file is a bad thing, but if it's controlled by the same connection string, it makes a lot more sense. So I think +1 for different defaults based on sslmode, but -1 on the strange naming. (not to say we can't fix the naming that's there now, but this specific suggestion makes it worse) /Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
On 12 apr 2009, at 11.13, Peter Eisentraut wrote:
On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
"sslmode=prefer" honestly makes no sense - if I don't care if it
ends up
encrypted or not (which it means), then why not just run with SSL off
and not have to deal with the overhead?
Perhaps a large part of the problem at hand is in fact that the
default is
sslmode=prefer, which, if the server is set up with some snakeoil
certificate,
causes all these cn verification problems, when the user really
didn't care in
the first place.
Another thing is that not all combinations of sslmode and sslverify
make
sense. If the user cares little about SSL ("allow", "prefer"), then
insisting
on a verifyable certificate is pointless.
Yeah, agreed.
One random idea is to fold both of these settings into sslmode, with
the
following progression:
disable, allow, prefer, require, require-cert, require-cn
And then set the default to "disable", because as you say "prefer"
is pretty
silly. And then users can explictly choose which level of SSL-ness
they want.
This is a different way to do bruces suggestion of a different
default. That's possibly even clearer. So I can definitely go with
this, but I think two different parameters makes it more clear and is
better.
And +1 for changing the default sslmode regardless of how we configure
ssl verification.
/Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> One random idea is to fold both of these settings into sslmode, with
>>> the
>>> following progression:
>>>
>>> disable, allow, prefer, require, require-cert, require-cn
>>>
>>> And then set the default to "disable", because as you say "prefer"
>>> is pretty
>>> silly. And then users can explictly choose which level of SSL-ness
>>> they want.
>> This is a different way to do bruces suggestion of a different
>> default. That's possibly even clearer. So I can definitely go with
>> this, but I think two different parameters makes it more clear and is
>> better.
>>
>> And +1 for changing the default sslmode regardless of how we configure
>> ssl verification.
>
> I like Peter's idea too. Having _three_ SSL settings is overkill, and I
> like the idea of doing it with one parameter. As already pointed out,
> it makes no sense to do server certificate verification unless the
> sslmode is 'require', and having require-cert and require-cn are very
> clear.
>
> I disagree with Magnus that having two parameters is better --- I think
> there is just too much risk of misconfiguration with two parameters.
Very well. One important part of having that would be to enable it by
default when you do "require", but there are other ways to accomplish
that of course.
> I would actually call the two parameters 'verify-cert' and 'verify-cn',
> and document that they also have "require" behavior. Obviously you
> can't verify certificates unless you require SSL.
I would prefer having "verify", "verify-no-cn" and "no-verify" or
something like that. Making it the "default choice" to have verification
enabled, and very clear that you're turning something off if you're not.
And then just map require to verify. Or they could be "require-no-cn"
and "require-no-cert" perhaps?
("default choice" only for those using ssl of course - we'd still have
"disable" as the default *value* of the parameter)
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Hiroshi Inoue wrote: > Magnus Hagander wrote: >> Hiroshi Inoue wrote: >>> Magnus Hagander wrote: >>>> Bruce Momjian wrote: >>>>> Martin Pitt wrote: >>>>>> I do see the benefit of failing to connect to an SSL-enabled server >>>>>> *if* I have a root.crt which doesn't match. But why fail if I don't >>>>>> have one? >>>>> I have digested this thread, and have done two things: improved the >>>>> documentation and posted a patch to make the error message clearer. >>>>> >>>>> In terms of your suggestion about root.crt, I think sslverify != none >>>>> should error if it can't verify the server's certificate, whether the >>>>> root.crt file is there or not. If you are asking for sslverify, it >>>>> should do that or error, not ignore the setting if there is no >>>>> root.crt >>>>> file. The only other approach would be to add an sslverify value of >>>>> 'try' that tries only if root.crt exists. >>>> Doesn't "try" make the whole check pretty pointless, and you can just >>>> set it to "none" then? >>> Yes the snapshot psqlodbc driver already set sslverify to none and can't >>> change it though it may be differnet from the expected behavior. It was >>> not so easy to implement because sslverify parameter is illegal for <= >>> 8.3 libpq and the psqlodbc driver doesn't rely on environment variables >>> at all. >> >> Whatever the default is, if you can't change the value I'd say that >> makes the ODBC driver pretty darn broken. It would be equally broken if >> it was set to the default and it wasn't possible to change it. > > The psqlodbc driver has its own development cycle and doesn't use new > core features at once usually. The problem is the default behavior about > sslverify is incompatible with the 8.3 libpq behavior and the driver had > to do something with it before 8.4 release. What the snapshot driver > actualy does is to simply hide the *sslverify* functionality. I thought you were talking about a release version. If it's just a snapshot, that is of course Ok. My apologies. Though it might be easier even in that case to use an environment variable to override it - that way the user could still override the ODBC driver if you just checked if the variable was present before you set it. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
On 14 apr 2009, at 04.33, Bruce Momjian wrote:
Magnus Hagander wrote:
I would actually call the two parameters 'verify-cert' and 'verify-
cn',
and document that they also have "require" behavior. Obviously you
can't verify certificates unless you require SSL.
I would prefer having "verify", "verify-no-cn" and "no-verify" or
something like that. Making it the "default choice" to have
verification
enabled, and very clear that you're turning something off if you're
not.
And then just map require to verify. Or they could be "require-no-cn"
and "require-no-cert" perhaps?
("default choice" only for those using ssl of course - we'd still
have
"disable" as the default *value* of the parameter)
I think the "no" options are odd because they have _negative_
designations.
That's the intention. When you're turning off something, I think it
makes sense to use "no"
/Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
>>
>>> Magnus Hagander wrote:
>>>>> I would actually call the two parameters 'verify-cert' and 'verify-
>>>>> cn',
>>>>> and document that they also have "require" behavior. Obviously you
>>>>> can't verify certificates unless you require SSL.
>>>> I would prefer having "verify", "verify-no-cn" and "no-verify" or
>>>> something like that. Making it the "default choice" to have
>>>> verification
>>>> enabled, and very clear that you're turning something off if you're
>>>> not.
>>>> And then just map require to verify. Or they could be "require-no-cn"
>>>> and "require-no-cert" perhaps?
>>>>
>>>> ("default choice" only for those using ssl of course - we'd still
>>>> have
>>>> "disable" as the default *value* of the parameter)
>>> I think the "no" options are odd because they have _negative_
>>> designations.
>> That's the intention. When you're turning off something, I think it
>> makes sense to use "no"
>
> But that doesn't scale: sslmode currently has four options, soon
> perhaps to be six. The idea is that the items should be of increasing
> security, and adding "no" in the middle doesn't allow that to be clear.
Here's a patch for this. Obviously, a lot needs to be done about the
docs here, I'm working on that.
I went with the names "require", "verify-ca" and "verify-full".
Patch also changes the default from "prefer" to "disable", per discussion.
Comments?
//Magnus
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
***
*** 270,276
! disable
only try a non-SSL connection
--- 270,276
! disable (default)
only try a non-SSL connection
***
*** 282,288
! prefer (default)
first try an SSL connection; if
that fails, try a non-SSL
connection
--- 282,288
! prefer
first try an SSL connection; if
that fails, try a non-SSL
connection
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
***
*** 90,102 static int ldapServiceLookup(const char *purl, PQconninfoOption *options,
#define DefaultOption ""
#define DefaultAuthtype ""
#define DefaultPassword ""
- #ifdef USE_SSL
- #define DefaultSSLMode "prefer"
- #define DefaultSSLVerify "cn"
- #else
#define DefaultSSLMode "disable"
- #define DefaultSSLVerify "none"
- #endif
/* --
* Definition of the conninfo parameters and their fallback resources.
--- 90,96
***
*** 185,193 static const PQconninfoOption PQconninfoOptions[] = {
{"sslmode", "PGSSLMODE", DefaultSSLMode, NULL,
"SSL-Mode", "", 8}, /* sizeof("disable") == 8 */
- {"sslverify", "PGSSLVERIFY", DefaultSSLVerify, NULL,
- "SSL-Verify", "", 5}, /* sizeof("chain") == 5 */
-
{"sslcert", "PGSSLCERT", NULL, NULL,
"SSL-Client-Cert", "", 64},
--- 179,184
***
*** 431,438 connectOptions1(PGconn *conn, const char *conninfo)
conn->connect_timeout = tmp ? strdup(tmp) : NULL;
tmp = conninfo_getval(connOptions, "sslmode");
conn->sslmode = tmp ? strdup(tmp) : NULL;
- tmp = conninfo_getval(connOptions, "sslverify");
- conn->sslverify = tmp ? strdup(tmp) : NULL;
tmp = conninfo_getval(connOptions, "sslkey");
conn->sslkey = tmp ? strdup(tmp) : NULL;
tmp = conninfo_getval(connOptions, "sslcert");
--- 422,427
***
*** 522,528 connectOptions2(PGconn *conn)
if (strcmp(conn->sslmode, "disable") != 0
&& strcmp(conn->sslmode, "allow") != 0
&& strcmp(conn->sslmode, "prefer") != 0
! && strcmp(conn->sslmode, "require") != 0)
{
conn->status = CONNECTION_BAD;
printfPQExpBuffer(&conn->errorMessage,
--- 511,519
if (strcmp(conn-
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Patch also changes the default from "prefer" to "disable", per discussion. > > I confess to not having paid attention to this thread for awhile. > I have to violently object to this conclusion --- it is throwing the > baby out with the bathwater. Under the pretense of being "secure by > default" it will in fact make things *less* secure. A minimum > requirement in my view is that existing configurations should continue > to work and be no less secure than before. Having a connection that > was encrypted in 8.3 silently become clear-text after installing 8.4 > is just plain NOT acceptable. > > I think the patch would be fine if we simply keep the default where > it is, however. Is there some point I am missing that compels > selection of a less-secure default? The current default *makes no sense*. Ever. Not just as a default. However, I can see us having "allow" instead of "disable" as the default. That is the most forgiving of all settings - it will work with whatever you had configured before. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Tom Lane wrote: >>> Having a connection that >>> was encrypted in 8.3 silently become clear-text after installing 8.4 >>> is just plain NOT acceptable. >>> >>> I think the patch would be fine if we simply keep the default where >>> it is, however. Is there some point I am missing that compels >>> selection of a less-secure default? > >> The current default *makes no sense*. Ever. Not just as a default. > > I categorically reject that thinking. Encrypted connections are useful > even without authentication. Your argument ignores the real fact that > eavesdropping is easier than man-in-the-middle attacks. Even if there > weren't any significant difference, what is the gain from switching to > unencrypted in cases where we previously used encryption? There is > none. Did you read the thread? That's not the argument that makes it make no sense. Yes, encrypted connections are useful without authentication. But they are quite useless unless you can determine if you have encryption *at all* before you start sending sensitive data. >> However, I can see us having "allow" instead of "disable" as the >> default. That is the most forgiving of all settings - it will work with >> whatever you had configured before. > > And it still moves us to "less secure than 8.3 by default", because > configurations that formerly used encrypted connections might now use > unencrypted ones. It's not acceptable. Fine. I'll leave the default as it is then, and document that the default we've chosen means "I don't care if I get security or not, but if possible, I'd like to pay the encryption overhead". //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote: > Tom Lane wrote: >> Magnus Hagander writes: >>> Tom Lane wrote: >>>> Having a connection that >>>> was encrypted in 8.3 silently become clear-text after installing 8.4 >>>> is just plain NOT acceptable. >>>> >>>> I think the patch would be fine if we simply keep the default where >>>> it is, however. Is there some point I am missing that compels >>>> selection of a less-secure default? >>> The current default *makes no sense*. Ever. Not just as a default. >> I categorically reject that thinking. Encrypted connections are useful >> even without authentication. Your argument ignores the real fact that >> eavesdropping is easier than man-in-the-middle attacks. Even if there >> weren't any significant difference, what is the gain from switching to >> unencrypted in cases where we previously used encryption? There is >> none. > > Did you read the thread? That's not the argument that makes it make no > sense. > > Yes, encrypted connections are useful without authentication. But they > are quite useless unless you can determine if you have encryption *at > all* before you start sending sensitive data. > > >>> However, I can see us having "allow" instead of "disable" as the >>> default. That is the most forgiving of all settings - it will work with >>> whatever you had configured before. >> And it still moves us to "less secure than 8.3 by default", because >> configurations that formerly used encrypted connections might now use >> unencrypted ones. It's not acceptable. > > Fine. I'll leave the default as it is then, and document that the > default we've chosen means "I don't care if I get security or not, but > if possible, I'd like to pay the encryption overhead". > I have applied a patch that does this. There are some further documentation updates required, I'll keep working on those. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote: > Magnus Hagander wrote: >> Tom Lane wrote: >>> Magnus Hagander writes: >>>> Tom Lane wrote: >>>>> Having a connection that >>>>> was encrypted in 8.3 silently become clear-text after installing 8.4 >>>>> is just plain NOT acceptable. >>>>> >>>>> I think the patch would be fine if we simply keep the default where >>>>> it is, however. Is there some point I am missing that compels >>>>> selection of a less-secure default? >>>> The current default *makes no sense*. Ever. Not just as a default. >>> I categorically reject that thinking. Encrypted connections are useful >>> even without authentication. Your argument ignores the real fact that >>> eavesdropping is easier than man-in-the-middle attacks. Even if there >>> weren't any significant difference, what is the gain from switching to >>> unencrypted in cases where we previously used encryption? There is >>> none. >> Did you read the thread? That's not the argument that makes it make no >> sense. >> >> Yes, encrypted connections are useful without authentication. But they >> are quite useless unless you can determine if you have encryption *at >> all* before you start sending sensitive data. >> >> >>>> However, I can see us having "allow" instead of "disable" as the >>>> default. That is the most forgiving of all settings - it will work with >>>> whatever you had configured before. >>> And it still moves us to "less secure than 8.3 by default", because >>> configurations that formerly used encrypted connections might now use >>> unencrypted ones. It's not acceptable. >> Fine. I'll leave the default as it is then, and document that the >> default we've chosen means "I don't care if I get security or not, but >> if possible, I'd like to pay the encryption overhead". >> > > I have applied a patch that does this. > > There are some further documentation updates required, I'll keep working > on those. I've committed another set of docs, which I think means I'm done. Comments are welcome. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4791: NULL value in function causes reproducible segmentation fault
Sikkerhed.org ApS wrote: > The following bug has been logged online: > > Bug reference: 4791 > Logged by: Sikkerhed.org ApS > Email address: supp...@sikkerhed.org > PostgreSQL version: 8.3.7-0lenny1 > Operating system: Debian GNU/Linux 5.0.1 stable (fully updated) > Description:NULL value in function causes reproducible segmentation > fault > Details: > > We are using a couple of functions in PostgreSQL, namely > > CREATE OR REPLACE FUNCTION digest(text, text) RETURNS bytea AS > '$libdir/pgcrypto', 'pg_digest' LANGUAGE 'C'; This declaration is incorrect. The function is from pgcrypto, and the pgcrypto declaration is: CREATE OR REPLACE FUNCTION digest(text, text) RETURNS bytea AS '$libdir/pgcrypto', 'pg_digest' LANGUAGE C IMMUTABLE STRICT; Notice the "immutable script" part that you are missing. Any particular reason why you are not using the pgcrypto installation script? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] unconfirmed bug #4784
Jörg Kiegeland wrote: > Hi, > Approx. 2 weeks ago, I posted a bug which got the ID 4784. However I got > no response to it, and it not occurs in the mbox of April or May. > This bug is quite important to us, since it was reported by our > customer. So I would like to know if this bug is still being checked / > on a waiting list to be checked, > or if it is somehow lost. Hi, since it's not available in the archives, it appears not to have been delivered to the lists. My bet is that it got caught in the spamfilter (the traffic from the bug report form goes to a standard mailinglist, so it's subject to the same antispam as other posts). We did have some issues with the spamfilter a couple of weeks ago, so it may have been lost then. Please resubmit the bugreport. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Tom Lane wrote: > Peter Koczan writes: >> This is trust authentication with one rather inconsequential bit of >> verification, that's a fundamental breakage. One of the major points >> of Kerberos is that, for anything that talks Kerberos, you are the >> principal in that ticket. I understand the desire to change some of >> that old code, but why is that principal being ignored? > > Well, the reason for that change was that the libpq code was absorbing > userid from any available Kerberos ticket, even if the server > subsequently issued a non-Kerberos authentication challenge. I still > think that was wrong. What your complaint seems to suggest is that > the server-side Kerberos auth code should be insisting that the supplied > principal's first component match the requested database userid. > I kinda thought we *had* been doing that, but can't claim to have read > that code closely. Magnus? We are certainly *supposed* to do that. And we have been doing that. So if that's not done, it's been broken in 8.4 (most likely by me). Peter, are you using gssapi or krb5? Only krb5 has changed wrt libpq, but from your messages it looks like you have gssapi? Can you show us your pg_hba.conf file, and all lines with krb in them from postgresql.conf? Also, can you try it with the server set to log at DEBUG4, and let us know what output you get? -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Magnus Hagander wrote: > Tom Lane wrote: >> Peter Koczan writes: >>> This is trust authentication with one rather inconsequential bit of >>> verification, that's a fundamental breakage. One of the major points >>> of Kerberos is that, for anything that talks Kerberos, you are the >>> principal in that ticket. I understand the desire to change some of >>> that old code, but why is that principal being ignored? >> Well, the reason for that change was that the libpq code was absorbing >> userid from any available Kerberos ticket, even if the server >> subsequently issued a non-Kerberos authentication challenge. I still >> think that was wrong. What your complaint seems to suggest is that >> the server-side Kerberos auth code should be insisting that the supplied >> principal's first component match the requested database userid. >> I kinda thought we *had* been doing that, but can't claim to have read >> that code closely. Magnus? > > We are certainly *supposed* to do that. And we have been doing that. So > if that's not done, it's been broken in 8.4 (most likely by me). > > Peter, are you using gssapi or krb5? Only krb5 has changed wrt libpq, > but from your messages it looks like you have gssapi? > > Can you show us your pg_hba.conf file, and all lines with krb in them > from postgresql.conf? > > Also, can you try it with the server set to log at DEBUG4, and let us > know what output you get? Crap, I think I found the problem. Tom, or someone else... auth.c line 1076. I'm pretty sure that should be "return ret" not "return STATUS_OK". Wow, that's a bad bug :-O //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Peter Koczan wrote: > I don't know if it's much use now, but here you go. > May 27 15:37:29 mitchell postgres[30609]: [629-1] LOG: provided > username (koczan) and authenticated username (strivia) don't match > May 27 15:37:29 mitchell postgres[30609]: [630-1] LOG: connection > authorized: user=strivia database=postgres This seems to confirm my suspicions. We detect that the username is wrong, but we still don't reject the connection. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Tom Lane wrote: > Magnus Hagander writes: >> Tom, or someone else... auth.c line 1076. I'm pretty sure that should be >> "return ret" not "return STATUS_OK". > > Doh. yeah. WIll apply patch. >> Wow, that's a bad bug :-O > > Hey, that's what beta is for ;-) :-) Do we need to announce it somehow? > You might want to take a quick look for copy-and-pastes of same error. > I see none offhand, but ... Yeah, I looked over the other similar places and didn't find anything. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Magnus Hagander wrote: > Tom Lane wrote: >> Magnus Hagander writes: >>> Tom, or someone else... auth.c line 1076. I'm pretty sure that should be >>> "return ret" not "return STATUS_OK". >> Doh. > > yeah. WIll apply patch. And, applied. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Lars Kanis wrote:
> The following bug has been logged online:
>
> Bug reference: 4869
> Logged by: Lars Kanis
> Email address: ka...@comcard.de
> PostgreSQL version: 8.4rc1
> Operating system: Linux c1170lx 2.6.24-23-generic #1 SMP Wed Apr 1
> 21:47:28 UTC 2009 i686 GNU/Linux
> Description:No proper initialization of OpenSSL-Engine in libpq
> Details:
>
> When using OpenSSL-engine pkcs11 with PGSSLKEY=pkcs11:id_45 the
> authentication to the PG-server fails with "engine not initialized".
>
> According to the OpenSSL-docs
> (http://www.openssl.org/docs/crypto/engine.html) the structural reference
> returned by ENGINE_by_id needs to be initialized first before use. The
> buildin engine doesn't need this, but most of external engines don't work
> otherwise.
>
> Moreover the structural and functional references should be freed in any
> case.
>
>
> The following patch solves the problem:
This looks good in generael to me. I remember looking at the engine code
wondering why we didn't do that, but since I don't have a good
environment to test that part in, I forgot about it :(
Shouldn't there be an ENGINE_free() in the error path of ENGINE_init()?
Should we not also call ENGINE_finish() and ENGINE_free() in the success
path of this code? Your patch adds it to the case where we didn't get
the private key, but what if we did? I assume they should also go
outside the error path, per the attached patch - or will that break
their usage?
Can you test that and verify that it doesn't break for you?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index bfc0965..53ac526 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -690,6 +690,20 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
return 0;
}
+ if (ENGINE_init(engine_ptr) == 0)
+ {
+char *err = SSLerrmessage();
+
+printfPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("could not initialize SSL engine \"%s\": %s\n"),
+ engine_str, err);
+SSLerrfree(err);
+ENGINE_free(engine_ptr);
+free(engine_str);
+ERR_pop_to_mark();
+return 0;
+ }
+
*pkey = ENGINE_load_private_key(engine_ptr, engine_colon,
NULL, NULL);
if (*pkey == NULL)
@@ -700,10 +714,14 @@ client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
libpq_gettext("could not read private SSL key \"%s\" from engine \"%s\": %s\n"),
engine_colon, engine_str, err);
SSLerrfree(err);
+ENGINE_finish(engine_ptr);
+ENGINE_free(engine_ptr);
free(engine_str);
ERR_pop_to_mark();
return 0;
}
+ ENGINE_finish(engine_ptr);
+ ENGINE_free(engine_ptr);
free(engine_str);
fnbuf[0] = '\0'; /* indicate we're not going to load from a
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Lars Kanis wrote:
>>> The following patch solves the problem:
>> This looks good in generael to me. I remember looking at the engine code
>> wondering why we didn't do that, but since I don't have a good
>> environment to test that part in, I forgot about it :(
>>
>> Shouldn't there be an ENGINE_free() in the error path of ENGINE_init()?
> In the patch it is already there, isn't it?
Eh. So it is. Don't know where I got the idea that it didn't :-)
>> Should we not also call ENGINE_finish() and ENGINE_free() in the success
>> path of this code? Your patch adds it to the case where we didn't get
>> the private key, but what if we did? I assume they should also go
>> outside the error path, per the attached patch - or will that break
>> their usage?
> That's right. I thought about it, but I don't know where the right place is.
>
>> Can you test that and verify that it doesn't break for you?
> It breaks with Segmentation fault in my smartcard-based setup. The
> pkey-handle
> is all we have from the engine, when client_cert_cb() is finished. Obviously
> the ref-counting of openssl does not take the pkey-handle into account, so we
> need to keep the engine_ptr for later freeing.
So we need to keep the engine initialized during this time? Ugh. We
don't currently carry around the engine pointer. I guess we have to.
> close_SSL() should be the right place for ENGINE_finish() and ENGINE_free() ?
Yup.
How about the attached patch? Does it work for you?
A question from that then, for others, is it Ok to add a field to the
PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments?
Tom, perhaps?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/interfaces/libpq/fe-secure.c
--- b/src/interfaces/libpq/fe-secure.c
***
*** 669,683 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
)
{
/* Colon, but not in second character, treat as engine:key */
- ENGINE *engine_ptr;
char *engine_str = strdup(conn->sslkey);
char *engine_colon = strchr(engine_str, ':');
*engine_colon = '\0'; /* engine_str now has engine name */
engine_colon++; /* engine_colon now has key name */
! engine_ptr = ENGINE_by_id(engine_str);
! if (engine_ptr == NULL)
{
char *err = SSLerrmessage();
--- 669,682
)
{
/* Colon, but not in second character, treat as engine:key */
char *engine_str = strdup(conn->sslkey);
char *engine_colon = strchr(engine_str, ':');
*engine_colon = '\0'; /* engine_str now has engine name */
engine_colon++; /* engine_colon now has key name */
! conn->engine = ENGINE_by_id(engine_str);
! if (conn->engine == NULL)
{
char *err = SSLerrmessage();
***
*** 690,696 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
return 0;
}
! *pkey = ENGINE_load_private_key(engine_ptr, engine_colon,
NULL, NULL);
if (*pkey == NULL)
{
--- 689,710
return 0;
}
! if (ENGINE_init(conn->engine) == 0)
! {
! char *err = SSLerrmessage();
!
! printfPQExpBuffer(&conn->errorMessage,
! libpq_gettext("could not initialize SSL engine \"%s\": %s\n"),
! engine_str, err);
! SSLerrfree(err);
! ENGINE_free(conn->engine);
! conn->engine = NULL;
! free(engine_str);
! ERR_pop_to_mark();
! return 0;
! }
!
! *pkey = ENGINE_load_private_key(conn->engine, engine_colon,
NULL, NULL);
if (*pkey == NULL)
{
***
*** 700,705 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
--- 714,722
libpq_gettext("could not read private SSL key \"%s\" from engine \"%s\": %s\n"),
engine_colon, engine_str, err);
SSLerrfree(err);
+ ENGINE_finish(conn->engine);
+ ENGINE_free(conn->engine);
+ conn->engine = NULL;
free(engine_str);
ERR_pop_to_mark();
return 0;
***
*** 1217,1222 close_SSL(PGconn *conn)
--- 1234,1246
X509_free(conn->peer);
conn->peer = NULL;
}
+
+ if (conn->engine)
+ {
+ ENGINE_finish(conn->engine);
+ ENGINE_free(conn->engine);
+ conn->engine = NULL;
+ }
}
/*
*** a/src/interfaces/libpq/libpq-int.h
--- b/src/interfaces/libpq/libpq-int.h
***
*** 383,388 struct pg_conn
--- 383,389
X509 *peer; /* X509 cert of server */
char peer_dn[256 + 1]; /* peer distinguished name */
char peer_cn[SM_USER + 1]; /* peer common name */
+ ENGINE *engine; /* SSL engine, if any */
#endif
#ifdef ENABLE_GSS
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> A question from that then, for others, is it Ok to add a field to the >> PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments? > > Changing PGconn internals doesn't bother me, but ... > > IIUC this is a pre-existing bug/limitation in an extremely seldom-used > feature that we don't have any very good way to test. So I'm not really > excited about trying to fix it in RC at all. The chances of breaking > something seem much higher than the usefulness of the fix would warrant. > > I'd suggest holding the matter until 8.5 development opens. I think we'll see this feature used a lot more now, since we support client certificate authentication. I bet that's the reason why Lars is using it now, but wasn't using it before. Correct, Lars? That would be the argument for doing it now. We previously supported engines for client certificates, but using client certificates at all wasn't very useful in pre-8.4, and that's why it wasn't used almost at all. While I don't expect a huge number of users of it in 8.4, I think it is a *much* more useful feature now, and thus will be used a lot more. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
On 22 jun 2009, at 18.05, Tom Lane wrote: Magnus Hagander writes: How about the attached patch? Does it work for you? The existing references to typedef ENGINE and associated functions are wrapped in #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined (OPENSSL_NO_ENGINE) I rather imagine that this patch will cause complete failure in builds where that's not true. Yeah, that will have to be fixed. I'm also a bit concerned about wrapping a struct field inside such an #if, as that's likely to cause hard-to-debug problems if two compilations read libpq-int.h with different #define environments. Since it's a pointer we could just declare it as void, no? Or even #if between void and "real" pointer. Wouldn't that be safe? (we already have a similar issue with the whole #ifdef use_ssl, don't we? But having one isn't an excuse to create another of course…) /Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
On 22 jun 2009, at 17.46, Tom Lane wrote: Lars Kanis writes: Am Montag, 22. Juni 2009 16:38:32 schrieben Sie: Tom Lane wrote: IIUC this is a pre-existing bug/limitation in an extremely seldom- used feature that we don't have any very good way to test. So I'm not really excited about trying to fix it in RC at all. The chances of breaking something seem much higher than the usefulness of the fix would warrant. I think we'll see this feature used a lot more now, since we support client certificate authentication. I bet that's the reason why Lars is using it now, but wasn't using it before. Correct, Lars? That's right. Because clientside crypto engines and proper certificate authentication is supported now, I would like to use a strong smartcard-based login in our high security environment. OK, but I'm still worried about making a change of this sort (ie, modifying our interface to code that we don't control) so late in the release cycle. It seems like there is large potential for failure in contexts other than the one or two you are going to be able to test right now. Is there anything that can be done to reduce the risk? I share your concerns in general. But I think we nee to take into account that this simply does not work without the patch. So nobody should rely on the previous behaviour - how would their application work there... (I guess there is always a risk I get to eat those words later if someone did, but I don't see the scenario...) in fact, this is a but in an advertised feature in previous versions, so should maybe even consider backpatching it base on that /Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> On 22 jun 2009, at 17.46, Tom Lane wrote: >>> It seems like there is large potential for failure in >>> contexts other than the one or two you are going to be able to test >>> right now. Is there anything that can be done to reduce the risk? > >> I share your concerns in general. But I think we nee to take into >> account that this simply does not work without the patch. > > Frankly, I don't much care whether openssl-with-an-external-engine > works; we never supported that before, and if it doesn't work now, Sure we did. It's in 8.3. It may not have ever worked properly, but that's a different thing. According do our code and documentation, the feature is there and supported. > that's not a regression. What I'm worried about at this stage of the > release cycle is regressions, eg, does the code still compile at all > with openssl version 0.9.random-version-that-used-to-work. Right, and we don't cover *that* many different versions with the buildfarm... So how about this: 1) We add a note to the documentation that states explicitly that this only works for engines that don't require intialization. 2) We add a section on the wiki for patches that fix known issues in 8.4, but that may cause behavioral changes and thus don't get applied to the main code until 8.5. I'm sure there will be other patches on this list eventually (after release time). Perhaps even a reference from #1 to #2? -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Lars Kanis wrote: > Am Montag, 22. Juni 2009 17:46:22 schrieben Sie: >> Lars Kanis writes: >>> Am Montag, 22. Juni 2009 16:38:32 schrieben Sie: >>>> Tom Lane wrote: >>>>> IIUC this is a pre-existing bug/limitation in an extremely seldom-used >>>>> feature that we don't have any very good way to test. So I'm not >>>>> really excited about trying to fix it in RC at all. The chances of >>>>> breaking something seem much higher than the usefulness of the fix >>>>> would warrant. >>>> I think we'll see this feature used a lot more now, since we support >>>> client certificate authentication. I bet that's the reason why Lars is >>>> using it now, but wasn't using it before. Correct, Lars? >>> That's right. Because clientside crypto engines and proper certificate >>> authentication is supported now, I would like to use a strong >>> smartcard-based login in our high security environment. >> OK, but I'm still worried about making a change of this sort (ie, >> modifying our interface to code that we don't control) so late in the >> release cycle. It seems like there is large potential for failure in >> contexts other than the one or two you are going to be able to test >> right now. Is there anything that can be done to reduce the risk? > > The 3 different versions of the engine-code seems to me like this: > > 1. unpatched libpq > engines aren't initialized (so some don't work), engines aren't freed at the > end of connection (memory leak), no changes to PGconn > > 2. the initial patch I posted > engines are initialized (so can work), engines aren't freed (memory leak), no > changes to PGconn only in engine code path > > 3. the current patch > engines are initialized, engines are freed, but problematic changes to PGconn > > > Maybe version 2 (my initial patch) could be an alternative ? Well, based on the "we don't know which different versions of openssl it'll break with", version 2 is no better than version 3 :( -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> Lars Kanis wrote: >>> Maybe version 2 (my initial patch) could be an alternative ? > >> Well, based on the "we don't know which different versions of openssl >> it'll break with", version 2 is no better than version 3 :( > > Yeah, if we do anything I think it should be more like #3. > > I think all or most back releases of openssl are available from > openssl.org. If someone had time to do a test compile of the proposed > patch against all of 'em (or at least all the ones we still claim to > support), it would salve my worries at least a bit. I'm not sure if > that's a big task or not, though. Well, if it's just to compile it, I guess it should even be scriptable :-) I'm not going to volunteer for that myself since I'm not sure I'll have the time. I can try to, but it's better if someone else has the time. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> Lars Kanis wrote: >>> Maybe version 2 (my initial patch) could be an alternative ? > >> Well, based on the "we don't know which different versions of openssl >> it'll break with", version 2 is no better than version 3 :( > > Yeah, if we do anything I think it should be more like #3. > > I think all or most back releases of openssl are available from > openssl.org. If someone had time to do a test compile of the proposed > patch against all of 'em (or at least all the ones we still claim to > support), it would salve my worries at least a bit. I'm not sure if > that's a big task or not, though. I ran a build with OpenSSL 0.9.8 (default on my machine) and 0.9.7. AFAICS, only 0.9.8 is supported at all these days. There is no point in running against <0.9.7, since there was no engine support in that. I tried 0.9.7m, 0.9.7c, 0.9.8g (Ubuntu) and 0.9.8b just to be sure. But they do seem to have a policy similar to our own - no features in backbranches. I only tested building (make clean, re-configure, make in pg) and it worked fine. Default configuration on OpenSSL. This is certainly not an exhaustive test, but I think it does a fair job of bracketing the possible versions with issues. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote:
> Magnus Hagander writes:
>> On 22 jun 2009, at 18.05, Tom Lane wrote:
>>> I'm also a bit concerned about wrapping a struct
>>> field inside such an #if, as that's likely to cause hard-to-debug
>>> problems if two compilations read libpq-int.h with different #define
>>> environments.
>
>> Since it's a pointer we could just declare it as void, no? Or even #if
>> between void and "real" pointer. Wouldn't that be safe?
>
> Yeah, on reflection I think it'd be safe to do
>
> #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
> ENGINE *ptr;
> #else
> /* dummy field to keep struct the same if OpenSSL version changes */
> void*ptr;
> #endif
>
> (probably that #if should get wrapped up in an additional #define
> instead of being duplicated in several places...)
Attached is an updated patch that does both of these.
>> (we already have a similar issue with the whole #ifdef use_ssl, don't
>> we? But having one isn't an excuse to create another of course…)
>
> That's controlled by an entry in pg_config.h, though, and won't change
> if someone happens to update their openssl install and then recompile
> only parts of libpq.
True, agreed.
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/interfaces/libpq/fe-secure.c
--- b/src/interfaces/libpq/fe-secure.c
***
*** 31,36
--- 31,37
#include "libpq-fe.h"
#include "fe-auth.h"
#include "pqsignal.h"
+ #include "libpq-int.h"
#ifdef WIN32
#include "win32.h"
***
*** 62,68
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L)
#include
#endif
! #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
#include
#endif
--- 63,69
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L)
#include
#endif
! #ifdef USE_SSL_ENGINE
#include
#endif
***
*** 661,667 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
*/
if (conn->sslkey && strlen(conn->sslkey) > 0)
{
! #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
if (strchr(conn->sslkey, ':')
#ifdef WIN32
&& conn->sslkey[1] != ':'
--- 662,668
*/
if (conn->sslkey && strlen(conn->sslkey) > 0)
{
! #ifdef USE_SSL_ENGINE
if (strchr(conn->sslkey, ':')
#ifdef WIN32
&& conn->sslkey[1] != ':'
***
*** 669,683 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
)
{
/* Colon, but not in second character, treat as engine:key */
- ENGINE *engine_ptr;
char *engine_str = strdup(conn->sslkey);
char *engine_colon = strchr(engine_str, ':');
*engine_colon = '\0'; /* engine_str now has engine name */
engine_colon++; /* engine_colon now has key name */
! engine_ptr = ENGINE_by_id(engine_str);
! if (engine_ptr == NULL)
{
char *err = SSLerrmessage();
--- 670,683
)
{
/* Colon, but not in second character, treat as engine:key */
char *engine_str = strdup(conn->sslkey);
char *engine_colon = strchr(engine_str, ':');
*engine_colon = '\0'; /* engine_str now has engine name */
engine_colon++; /* engine_colon now has key name */
! conn->engine = ENGINE_by_id(engine_str);
! if (conn->engine == NULL)
{
char *err = SSLerrmessage();
***
*** 690,696 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
return 0;
}
! *pkey = ENGINE_load_private_key(engine_ptr, engine_colon,
NULL, NULL);
if (*pkey == NULL)
{
--- 690,711
return 0;
}
! if (ENGINE_init(conn->engine) == 0)
! {
! char *err = SSLerrmessage();
!
! printfPQExpBuffer(&conn->errorMessage,
! libpq_gettext("could not initialize SSL engine \"%s\": %s\n"),
! engine_str, err);
! SSLerrfree(err);
! ENGINE_free(conn->engine);
! conn->engine = NULL;
! free(engine_str);
! ERR_pop_to_mark();
! return 0;
! }
!
! *pkey = ENGINE_load_private_key(conn->engine, engine_colon,
NULL, NULL);
if (*pkey == NULL)
{
***
*** 700,705 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
--- 715,723
libpq_gettext("could not read private SSL key \"%s\" from engine \"%s\": %s\n"),
engine_colon, engine_str, err);
SSLerrfree(err);
+ ENGINE_finish(conn->engine);
+ E
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
Andrew Chernow wrote:
> TAKATSUKA Haruka wrote:
>> Hi.
>>
>> We found the unbalance of xxAlloc and xxFree at AddUserToDacl() in
>> src/port/exec.c (of current HEAD code).
>>
>> psidUser is a pointer of the element of a TOKEN_USER structure
>> allocated by HeapAlloc(). The FreeSid() frees a SID allocated by
>> AllocateAndInitializeSid(). I think that it is correct to use
>> HeapFree(GetProcessHeap(), 0, pTokenUser).
>>
>> At present, a specific error, crash or trouble seems not to have
>> happened.
>>
>>
>> src/port/exec.c:748 AddUserToDacl()
>> src/port/exec.c:841 GetUserSid()
>> pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(),
>> HEAP_ZERO_MEMORY, dwLength);
>>
>> src/port/exec.c:807 AddUserToDacl()
>> FreeSid(psidUser);
>
> I quickly poked around and found what I believe to be two memory issues.
>
> 1. GetUserSid() uses HeapAlloc() to allocate a TOKEN_USER, but never
> calls HeapFree() if the function succeeds. Instead, it pulls out the
> token's SID and returns it. This is a memory leak.
>
> 2. The SID returned by GetUserSid() is incorrectly being passed to
> FreeSid() within AddUserToDacl()'s cleanup section. This memory belongs
> to the TOKEN_USER allocated by HeapAlloc() in GetUserSid(), it cannot be
> passed to FreeSid.
>
> Quick question, Why HeapAlloc and LocalAlloc. Why not use malloc?
>
> One solution would be to return a copy of the SID from GetUserSid and
> HeapFree the TOKEN_USER.
>
> Replace GetUserSid() line 869
>
> *ppSidUser = pTokenUser->User.Sid;
> return TRUE;
>
> With the below (error checking excluded)
>
> DWORD len = GetLengthSid(pTokenUser->User.Sid)
> *ppSidUser = (PSID) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
> CopySid(len, *ppSidUser, pTokenUser->User.Sid);
>
> // SID is copied, free TOKEN_USER
> HeapFree(GetProcessHeap(), 0, pTokenUser);
> return TRUE;
>
> Also, AddUserToDacl() line 807
>
> FreeSid(psidUser) should be HeapFree(GetProcessHeap(), 0, psidUser)
>
> in order to work with my suggested changes in GetUserSid().
How about something like this? I switched to using LocalAlloc() in all
places to be consistent, instead of mixing heap and local. (Though per
doc, LocalAlloc is actually a wrapper for HeapAlloc in win32).
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/port/exec.c
--- b/src/port/exec.c
***
*** 804,810 AddUserToDacl(HANDLE hProcess)
cleanup:
if (psidUser)
! FreeSid(psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
--- 804,810
cleanup:
if (psidUser)
! LocalFree((HLOCAL) psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
***
*** 822,827 cleanup:
--- 822,830
* GetUserSid*PSID *ppSidUser, HANDLE hToken)
*
* Get the SID for the current user
+ *
+ * The caller of this function is responsible for calling LocalFree() on the
+ * returned SID area.
*/
static BOOL
GetUserSid(PSID *ppSidUser, HANDLE hToken)
***
*** 838,844 GetUserSid(PSID *ppSidUser, HANDLE hToken)
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwLength);
if (pTokenUser == NULL)
{
--- 841,847
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! pTokenUser = (PTOKEN_USER) LocalAlloc(LPTR, dwLength);
if (pTokenUser == NULL)
{
***
*** 859,872 GetUserSid(PSID *ppSidUser, HANDLE hToken)
dwLength,
&dwLength))
{
! HeapFree(GetProcessHeap(), 0, pTokenUser);
pTokenUser = NULL;
log_error("could not get token information: %lu", GetLastError());
return FALSE;
}
! *ppSidUser = pTokenUser->User.Sid;
return TRUE;
}
--- 862,895
dwLength,
&dwLength))
{
! LocalFree(pTokenUser);
pTokenUser = NULL;
log_error("could not get token information: %lu", GetLastError());
return FALSE;
}
! /*
! * Need to copy the data to a separate buffer, so we can free our buffer
! * and let the caller free only the sid part.
! */
! dwLength = GetLengthSid(pTokenUser->User.Sid);
! *ppSidUser = (PSID) LocalAlloc(LPTR, dwLength);
! if (!*ppSidUser)
! {
! LocalFree(pTokenUser);
! log_error("could not allocate %lu bytes of memory", dwLength);
! return FALSE;
! }
! if (!CopySid(dwLength, *ppSidUser, pTokenUser->User.Sid))
! {
! LocalFree(*ppSidUser);
! LocalFree(pTokenUser);
! log_error("could not copy SID: %lu", GetLastError());
! return FALSE;
! }
!
! LocalFree(pTokenUser);
return TRUE;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> Attached is an updated patch that does both of these. > > This looks reasonably sane to me, and I'm satisfied with the testing > that's been done. No objection from here. Applied. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
Jim Michaels wrote: > The following bug has been logged online: > > Bug reference: 4876 > Logged by: Jim Michaels > Email address: jmich...@yahoo.com > PostgreSQL version: 8.3.7-1 > Operating system: windows XP Pro SP3 > Description:author of MD5 says it's seriously broken - hash > collision resistance problems > Details: > > If you are looking for hash collision protection, start looking at SHA-256 > or SHA-512. > > "In any case, you may not want to be using md5 (at least for > applications requiring collision-resistance), as it is > seriously broken. Use SHA-256 instead." - Ronald Rivest (author of MD5) We are talking about two different uses here, I think. Using MD5 for passwords doesn't, afaik, actually require collision-resistance. It requires resistance against preimage-attacks, which there are none for MD5. At least not yet. The other use is for hashes in the application, for users of pgcrypto. pgcrypto already provides SHA-256 and SHA-512 for this use. > I was using MD5 in my zapdupes program and was told by the author of MD5, > and switched to SHA-512, because of the size of the files I was dealing > with. since you have BLOBs, I suggest you do the same. There is no hashing of the BLOBs unless you build that into your application, in which case it's your responsibility to use a secure algorithm. PostgreSQL just stores it. > this has implications for storing passwords as MD5 hashes. My That would be the only system use of MD5. What implications are those? We might want to consider using a safer hash for the password storage at some point, but from what I gather it's not really urgent for *that* use. What would be more urgent is to provide a secure hashing *function* to end users that doesn't rely on pgcrypto. But there is a solution for this available today for those who need it - install pgcrypto. > I have implemented SHA-512 as GPL'd code that you may use at PostgreSQL is a BSD project and we have no use for GPL code. We also already have implementations of SHA256 and SHA512 that are BSD licensed in our codebase. > one possibility is that you could make the MD5 function actually return a > SHA-512 hash. That seems like a horrible idea. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4877: LDAP auth allows empty password string
Richard Tector wrote: > The following bug has been logged online: > > Bug reference: 4877 > Logged by: Richard Tector > Email address: rich...@tector.org.uk > PostgreSQL version: 8.3.7 > Operating system: FreeBSD 7.2-RELEASE-p1 > Description:LDAP auth allows empty password string > Details: > > In general the client libraries for PostgreSQL error if an empty password is > used. The JDBC drivers do not, and this has uncovered a problem with the > server's LDAP authentication code. > > When authenticating against Active Directory using the method: > ldap "ldap://osiris.capl.local/dc=capl,dc=local;CAPL\"; > Authentication is successful with both the correct password and an empty > password, so long as a valid user is supplied. Using a non-existent username > or an incorrect password correctly produces an error and the logon fails. Since this is a security related report, it should have been reported to secur...@postgresql.org, as specified on the web form you used. For this reason, we will follow this up on that forum, and post a public followup once the issue has been investigated. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
Andrew Chernow wrote:
>
>>
>> How about something like this? I switched to using LocalAlloc() in all
>> places to be consistent, instead of mixing heap and local. (Though per
>> doc, LocalAlloc is actually a wrapper for HeapAlloc in win32).
>
> Our patches crossed. Although, in my patch I left the allocation scheme
> alone since I wasn't sure if someone wanted that way. I'd suggest
> malloc and free if your going to change it. The only time I use an MS
> allocater is when a win32 api function specifically states it must be used.
Attached is a mix of our two patches. How does that look to you?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/port/exec.c
--- b/src/port/exec.c
***
*** 56,62 static int resolve_symlinks(char *path);
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetUserSid(PSID *ppSidUser, HANDLE hToken);
#endif
/*
--- 56,62
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser);
#endif
/*
***
*** 697,703 AddUserToDacl(HANDLE hProcess)
DWORD dwTokenInfoLength = 0;
HANDLE hToken = NULL;
PACL pacl = NULL;
! PSID psidUser = NULL;
TOKEN_DEFAULT_DACL tddNew;
TOKEN_DEFAULT_DACL *ptdd = NULL;
TOKEN_INFORMATION_CLASS tic = TokenDefaultDacl;
--- 697,703
DWORD dwTokenInfoLength = 0;
HANDLE hToken = NULL;
PACL pacl = NULL;
! PTOKEN_USER pTokenUser = NULL;
TOKEN_DEFAULT_DACL tddNew;
TOKEN_DEFAULT_DACL *ptdd = NULL;
TOKEN_INFORMATION_CLASS tic = TokenDefaultDacl;
***
*** 744,758 AddUserToDacl(HANDLE hProcess)
goto cleanup;
}
! /* Get the SID for the current user. We need to add this to the ACL. */
! if (!GetUserSid(&psidUser, hToken))
{
! log_error("could not get user SID: %lu", GetLastError());
goto cleanup;
}
/* Figure out the size of the new ACL */
! dwNewAclSize = asi.AclBytesInUse + sizeof(ACCESS_ALLOWED_ACE) + GetLengthSid(psidUser) -sizeof(DWORD);
/* Allocate the ACL buffer & initialize it */
pacl = (PACL) LocalAlloc(LPTR, dwNewAclSize);
--- 744,762
goto cleanup;
}
! /*
! * Get the user token for the current user, which provides us with the
! * SID that is needed for creating the ACL.
! */
! if (!GetTokenUser(hToken, &pTokenUser))
{
! log_error("could not get user token: %lu", GetLastError());
goto cleanup;
}
/* Figure out the size of the new ACL */
! dwNewAclSize = asi.AclBytesInUse + sizeof(ACCESS_ALLOWED_ACE) +
! GetLengthSid(pTokenUser->User.Sid) -sizeof(DWORD);
/* Allocate the ACL buffer & initialize it */
pacl = (PACL) LocalAlloc(LPTR, dwNewAclSize);
***
*** 785,791 AddUserToDacl(HANDLE hProcess)
}
/* Add the new ACE for the current user */
! if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, psidUser))
{
log_error("could not add access allowed ACE: %lu", GetLastError());
goto cleanup;
--- 789,795
}
/* Add the new ACE for the current user */
! if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, pTokenUser->User.Sid))
{
log_error("could not add access allowed ACE: %lu", GetLastError());
goto cleanup;
***
*** 803,810 AddUserToDacl(HANDLE hProcess)
ret = TRUE;
cleanup:
! if (psidUser)
! FreeSid(psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
--- 807,814
ret = TRUE;
cleanup:
! if (pTokenUser)
! LocalFree((HLOCAL) pTokenUser);
if (pacl)
LocalFree((HLOCAL) pacl);
***
*** 819,846 cleanup:
}
/*
! * GetUserSid*PSID *ppSidUser, HANDLE hToken)
*
! * Get the SID for the current user
*/
static BOOL
! GetUserSid(PSID *ppSidUser, HANDLE hToken)
{
DWORD dwLength;
- PTOKEN_USER pTokenUser = NULL;
if (!GetTokenInformation(hToken,
TokenUser,
! pTokenUser,
0,
&dwLength))
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwLength);
! if (pTokenUser == NULL)
{
log_error("could not allocate %lu bytes of memory", dwLength);
return FALSE;
--- 823,853
}
/*
! * GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser)
! *
! * Get the users token information from a process token.
*
! * The caller of this function is responsible for calling LocalFree() on the
! * returned TOKEN_USER memory.
*/
static BOOL
! GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser)
{
DWORD dwLength;
+ *ppTokenUser = NULL;
if (!GetTokenInformation(hToken,
TokenUser,
! NULL,
0,
&dw
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
Andrew Chernow wrote: >> >> Attached is a mix of our two patches. How does that look to you? >> > > looks good. The next obvious question is, is this something we care to backpatch (at this point, 8.4 is considered backpatch from that perspective), or should we hold for 8.5? The only issue now is a small leak of memory in a function that is only called a fixed (and very small) number of times per process. Given this, I'm inclined to say we should put it on hold for 8.5. Thoughts? -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
Andrew Chernow wrote: > >> The only issue now is a small leak of memory in a function that is only >> called a fixed (and very small) number of times per process. Given this, >> I'm inclined to say we should put it on hold for 8.5. Thoughts? >> >> > > Doesn't sound urgent to me. If it were my decision, I'd punt it to 8.5. Ok. Agreed then - added to the commitfest page. > Hard to keep that win32 acl stuff leak free. There is always a cleanup > goto because you need 6 billion objects to answer any question :o Yeah, true. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4932: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing
On Wed, Jul 22, 2009 at 11:42, Peter Much wrote: > > The following bug has been logged online: > > Bug reference: 4932 > Logged by: Peter Much > Email address: ...@citylink.dinoex.sub.org > PostgreSQL version: 8.4.0 > Operating system: FreeBSD 7.2 > Description: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing > Details: > > In chapter 19.3.5 of the manual an option "krb_server_hostname" is > mentioned. > This option was present in 8.2 but is no longer present in 8.4.0 It is present, only it has now been moved to pg_hba.conf. It is no longer in postgresql.conf. My guess is that you tried it configured the same way as in previous versions, where there was a global parameter in postgresql.conf? > So at least we have a documentation bug here. That page lists settings for pg_hba.conf, so I believe it is correct. However, suggestions for improvements are always welcome :-) > But the essential point seems to me the following: section 19.3.5 of the > manual reads "hostname is the fully qualified host name of the server > machine." > > But _there_is_no_such_thing_ as a "fully qualified hostname"! > There are only _fully_qualified_interface-names_, and any host can have > *many* of these. The hostname itself is nothing else than an arbitrary label > for the machine, and it should never be used by networking software. In a very large part of the cases, the fully qualified hostname will be the same as the fully qualified interface name for the only interface that's configured. Anyway, the whole reason for moving the krb_server_hostname parameter into pg_hba.conf is to make it *more* flexible to configure situations like this. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4932: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing
On Wed, Jul 22, 2009 at 17:29, Peter Much wrote: > On Wed, Jul 22, 2009 at 11:52:32AM +0200, Magnus Hagander wrote: > ! On Wed, Jul 22, 2009 at 11:42, Peter Much > wrote: > > Now understanding it, I bow in respect - this is indeed a fine > improvement! Thanks :-) > ! > But _there_is_no_such_thing_ as a "fully qualified hostname"! > > ! In a very large part of the cases, the fully qualified hostname will > ! be the same as the fully qualified interface name for the only > ! interface that's configured. > > Alright, frankly and just out of band of the topic, let me say > one thing: I am installing systems for the big commercial vendors > for more than a decade now, and this matter was an ongoing annoyance > all of the time. > While at first glance it may be considered just a matter of > convenience, the real trouble starts as soon as one does > high-availability solutions; these will definitely break on such > an assumption, and we end up with patching the hostname on takeover: > so having no functional mailer, unintellegible logfiles, not knowing > for sure on which hardware we admins are logged in, and similar > ugliness more. > Here I am talking about the commercial middleware vendors, who > are really stubborn in this matter - in the OpenSource the situation > is already a thousand times better! If you have any suggestions for improvements on either the documentation on the feature itself from someone who's deploying them "for real customers", that's always interesting. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4938: upgrade to 8.4 issue
On Thu, Jul 23, 2009 at 21:15, Anders Edstrom wrote: > > The following bug has been logged online: > > Bug reference: 4938 > Logged by: Anders Edstrom > Email address: a...@yahoo.com > PostgreSQL version: 8.3 > Operating system: Windows Vista > Description: upgrade to 8.4 issue > Details: > > Hi, > > When I run the installation of postgresql 8.4 I'm prompted for password. > When I issue the password I have for 8.3 (=dbpass)I get an error message > "invalid password" ?? > > I don't understand how that is possible since its the only password I have > ? You should have one password for the service account and one for the superuser. You are probably entering the password for the superuser - it needs the service account. > How can I reset the password so I can get the postgresql up and working > again, i.e. I have also now tried to uninstall 8.3 but get the same message > of invalid password? You can do this using the user management functions in the operating system, or using the "NET USER" command on the commandprompt. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgres user authentification or LDAP authentification
On Thu, Jul 23, 2009 at 12:47, Lauris Ulmanis wrote: > Hello! > > > > I posted you a message about slowness of creation users more than 500 000 > (#4919). It seems there is no workaround of this problem because of using > pg_auth flat file. > > > > To override this problem is it possible to use LDAP authentification metod > to identify each user and speed up system? No. LDAP authentication still requires all the users to be created in the database before they can log in. This is required so that they get an oid in the system, that is used for all permissions checks and ownership and such things. The only thing you could do here is to map multiple users to the *same* database user using pg_ident.conf, for example with a regular expression. However, you then loose the ability to distinguish between these users once they are logged in. > How it will affect group roles > for each user because we use groups roles to give Access to users to system > objects? Because group roles will work only with postgres users not LDAP. The PostgreSQL LDAP code currently has no support for groups. > pgBouncer or pgPool uses Postgres users for connection pooling. Is there > some more variants to use connection pooling without using postgres users? Not that I know of. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4938: upgrade to 8.4 issue
On Thu, Jul 23, 2009 at 23:40, Anders E wrote: > Hi again, > Are you swedish, then you can answer in Swedish if you like .. ? Yes, but let's keep it in english for the sake of the list. > I still can't get passed the request for password when trying to install 8.4 > ? > Don't know if I succeded to rest the password either. > Exactly how do I remove the password, I'm using Windows Vista? I have no experience using Windows Vista, so I don't know the exact procedure there. I suggest looking in the documentation for that. > I tried writing NET USER at the command prompt. > Shouldn't I also add something else in the command (not my strong side doing > this as you understand). Yes, you need to add the service account and new password. For example: NET USER postgres MyNewPassword > Or is there another way to get around the password request when installing > postgreSQL 8.4 ?? You can create a new service account with a different name. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
On Wed, Jun 24, 2009 at 16:01, Magnus Hagander wrote: > Andrew Chernow wrote: >> >>> The only issue now is a small leak of memory in a function that is only >>> called a fixed (and very small) number of times per process. Given this, >>> I'm inclined to say we should put it on hold for 8.5. Thoughts? >>> >>> >> >> Doesn't sound urgent to me. If it were my decision, I'd punt it to 8.5. > > Ok. Agreed then - added to the commitfest page. Applied to HEAD. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4947: libpq PQntuples should return 64-bit number
On Tue, Jul 28, 2009 at 08:54, Jim Michaels wrote: > > The following bug has been logged online: > > Bug reference: 4947 > Logged by: Jim Michaels > Email address: jmich...@yahoo.com > PostgreSQL version: 8.4.0 > Operating system: Win XP Pro Sp3 > Description: libpq PQntuples should return 64-bit number Why? Do you have an actual use-case where PQexec() would return more than 2 billion rows, and not have other much more complex issues? For example, the fact that they all have to be materialized in memory? Also, this would break compatibility with previous versions, so I think it would have to be a new function name, like PQntuples64(). But we'd have to see an actual use-case first... > I agree that 64-bit numbers are compiler-specific. this can be overcome > with something like the following code: > > although now I understand that the microsoft 2008 compiler implements > UINT128, UINT8, UINT64, UINT32, INT64 and the like, but the MINGW compiler > and BCC++5.5 do not necessarily implement them. > > maybe with some #if defined(INT64) the following code could be made proper. > something common to all 32-bit microsoft compilers is the __int64 type. You seem to be focused on the Windows platform there. There are a whole lot more platforms needed. But we already have generic types for 64-bit available in our headers, in the form of int64 and uint64. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Sat, Aug 1, 2009 at 01:49, Alvaro Herrera wrote: > Luke Koops wrote: > >> Description: Stats collector hung on WaitForMultipleObjectsEx while >> attempting to recv a datagram >> Details: >> >> While running a load test with 80 processes connected to postgres, of which >> 62 were generating load, the stats collector got blocked on >> WaitForMultipleObjectsEx which was called with INFINITE timeout. The stack >> trace for the hung thread follows: > > >> ntdll.dll!NtWaitForMultipleObjects+0xc >> kernel32.dll!WaitForMultipleObjectsEx+0x11a >> postgres.exe!pgwin32_waitforsinglesocket+0x1ed >> postgres.exe!pgwin32_recv+0x90 >> postgres.exe!PgstatCollectorMain+0x17f >> postgres.exe!SubPostmasterMain+0x33a >> postgres.exe!main+0x168 >> postgres.exe!__tmainCRTStartup+0x10f >> kernel32.dll!BaseProcessStart+0x23 > > I have seen this problem too. The process seems stuck for no good > reason. I wondered at the time if it could be a kernel issue. I > remember trying to send some data to the collector to verify whether > it'd wake up, but no luck. (I mean I couldn't find a way to do it on > Windows). I have seen this as well, but only in cases where there has been broken firewall software or such things involved. I have seen a couple of reports from the field though. Anyway, this really is a should-never-happen thing. As soon as a new packet is sent in, WaitForMultipleObjectsEx() should return right away. And given that backends regularly send packets over, it shouldn't be an issue even if we miss one... To generate packets, you should be able to use for example "nc" that is available as a win32 binary as well. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Mon, Aug 3, 2009 at 15:47, Nikhil Sontakke wrote: > Hi, > >>> >>> >>>> ntdll.dll!NtWaitForMultipleObjects+0xc >>>> kernel32.dll!WaitForMultipleObjectsEx+0x11a >>>> postgres.exe!pgwin32_waitforsinglesocket+0x1ed >>>> postgres.exe!pgwin32_recv+0x90 >>>> postgres.exe!PgstatCollectorMain+0x17f >>>> postgres.exe!SubPostmasterMain+0x33a >>>> postgres.exe!main+0x168 >>>> postgres.exe!__tmainCRTStartup+0x10f >>>> kernel32.dll!BaseProcessStart+0x23 >>> >>> I have seen this problem too. The process seems stuck for no good >>> reason. I wondered at the time if it could be a kernel issue. I >>> remember trying to send some data to the collector to verify whether >>> it'd wake up, but no luck. (I mean I couldn't find a way to do it on >>> Windows). >> >> I have seen this as well, but only in cases where there has been >> broken firewall software or such things involved. I have seen a couple >> of reports from the field though. >> >> Anyway, this really is a should-never-happen thing. As soon as a new >> packet is sent in, WaitForMultipleObjectsEx() should return right >> away. And given that backends regularly send packets over, it >> shouldn't be an issue even if we miss one... >> > > And this fact should lend credence to Alvaro's (as well as mine) > suspicions that it seems to be a Windows kernel issue. > > As a consequence, Magnus I was wondering if having a loop similar to > the WRITE handling of waiting for a fixed timeout in a loop (rather > than an INFINITE call to WaitForMultipleObjectsEx) inside the > pgwin32_waitforsinglesocket() function will help for the READ case > too? I believe Teogor Sigaev had raised a similar concern a while back > about it: > > http://www.nabble.com/-GENERAL--Stats-collector-frozen--td8569977i20.html Maybe. I'm unsure if it's enough to just try another WaitForSingleObjectEx() on it, or if we need to actually issue a WSARecv() on it as well. Maybe it would be enough to just change the INIFINTE on line 318 of socket.c to a fixed value. That will loop down to WSARecv() which should exit with WSAEWOULDBLOCK which will cause us to do a short sleep and come back. But we'd have to change the limit of 5 somehow then, since in theory we should wait forever. Maybe that outer loop should just be a for(;;), what do you think? From what I understand, none of you have an environment where you can reliably reproduce this? That means it's going to be a PITA to try to figure out if we're actually fixing anything :S -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Mon, Aug 3, 2009 at 16:12, Nikhil Sontakke wrote: > Hi, > >>>>> >>>>>> ntdll.dll!NtWaitForMultipleObjects+0xc >>>>>> kernel32.dll!WaitForMultipleObjectsEx+0x11a >>>>>> postgres.exe!pgwin32_waitforsinglesocket+0x1ed >>>>>> postgres.exe!pgwin32_recv+0x90 >>>>>> postgres.exe!PgstatCollectorMain+0x17f >>>>>> postgres.exe!SubPostmasterMain+0x33a >>>>>> postgres.exe!main+0x168 >>>>>> postgres.exe!__tmainCRTStartup+0x10f >>>>>> kernel32.dll!BaseProcessStart+0x23 >>>>> >>>>> I have seen this problem too. The process seems stuck for no good >>>>> reason. I wondered at the time if it could be a kernel issue. I >>>>> remember trying to send some data to the collector to verify whether >>>>> it'd wake up, but no luck. (I mean I couldn't find a way to do it on >>>>> Windows). >>>> >>>> I have seen this as well, but only in cases where there has been >>>> broken firewall software or such things involved. I have seen a couple >>>> of reports from the field though. >>>> >>>> Anyway, this really is a should-never-happen thing. As soon as a new >>>> packet is sent in, WaitForMultipleObjectsEx() should return right >>>> away. And given that backends regularly send packets over, it >>>> shouldn't be an issue even if we miss one... >>>> >>> >>> And this fact should lend credence to Alvaro's (as well as mine) >>> suspicions that it seems to be a Windows kernel issue. >>> >>> As a consequence, Magnus I was wondering if having a loop similar to >>> the WRITE handling of waiting for a fixed timeout in a loop (rather >>> than an INFINITE call to WaitForMultipleObjectsEx) inside the >>> pgwin32_waitforsinglesocket() function will help for the READ case >>> too? I believe Teogor Sigaev had raised a similar concern a while back >>> about it: >>> >>> http://www.nabble.com/-GENERAL--Stats-collector-frozen--td8569977i20.html >> >> Maybe. I'm unsure if it's enough to just try another >> WaitForSingleObjectEx() on it, or if we need to actually issue a >> WSARecv() on it as well. Maybe it would be enough to just change the >> INIFINTE on line 318 of socket.c to a fixed value. That will loop down >> to WSARecv() which should exit with WSAEWOULDBLOCK which will cause us >> to do a short sleep and come back. But we'd have to change the limit >> of 5 somehow then, since in theory we should wait forever. Maybe that >> outer loop should just be a for(;;), what do you think? >> > > Yes, line 318 seems to be a much better location to me. If Windows and > it's socket logic behaves properly most of the times :), most of the > calls should come out within the first few tries, so changing 5 to an > infinite loop shouldn't hurt those normal use cases in theory. > > OTOH, I was wondering what if we kill the stats collector and on a > restart the socket communication resumes properly. Would that > conclusively mean that it is a flaw in our code? No, if we kill the stats collector that will destroy all sockets, and when the new one starts all the sockets it operates on are fresh and new. So it doesn't show that the flaw is in our code - but it also doesn't show that it's in the kernel or runtime libraries. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Mon, Aug 3, 2009 at 16:20, Nikhil Sontakke wrote: > Hi, > >>>>> >>>>> And this fact should lend credence to Alvaro's (as well as mine) >>>>> suspicions that it seems to be a Windows kernel issue. >>>>> >>>>> As a consequence, Magnus I was wondering if having a loop similar to >>>>> the WRITE handling of waiting for a fixed timeout in a loop (rather >>>>> than an INFINITE call to WaitForMultipleObjectsEx) inside the >>>>> pgwin32_waitforsinglesocket() function will help for the READ case >>>>> too? I believe Teogor Sigaev had raised a similar concern a while back >>>>> about it: >>>>> >>>>> http://www.nabble.com/-GENERAL--Stats-collector-frozen--td8569977i20.html >>>> >>>> Maybe. I'm unsure if it's enough to just try another >>>> WaitForSingleObjectEx() on it, or if we need to actually issue a >>>> WSARecv() on it as well. Maybe it would be enough to just change the >>>> INIFINTE on line 318 of socket.c to a fixed value. That will loop down >>>> to WSARecv() which should exit with WSAEWOULDBLOCK which will cause us >>>> to do a short sleep and come back. But we'd have to change the limit >>>> of 5 somehow then, since in theory we should wait forever. Maybe that >>>> outer loop should just be a for(;;), what do you think? >>>> >>> >>> Yes, line 318 seems to be a much better location to me. If Windows and >>> it's socket logic behaves properly most of the times :), most of the >>> calls should come out within the first few tries, so changing 5 to an >>> infinite loop shouldn't hurt those normal use cases in theory. >>> >>> OTOH, I was wondering what if we kill the stats collector and on a >>> restart the socket communication resumes properly. Would that >>> conclusively mean that it is a flaw in our code? >> >> No, if we kill the stats collector that will destroy all sockets, and >> when the new one starts all the sockets it operates on are fresh and >> new. So it doesn't show that the flaw is in our code - but it also >> doesn't show that it's in the kernel or runtime libraries. >> > > AFAICS in the code, the inherited pgStatSock socket FD remains the > same across the restart of the stats collector process... Partially correct, I think. Each backend has it's own handle on win32, since we use EXEC_BACKEND (this includes the "utility processes" like the stats collector). When we start the new one, we are going to use DuplicateHandle() in save_backend_variables(). This will therefor get it a new handle, but they are both pointing to the same kernel object. I don't know if WaitForMultipleObjectsEx() is going to see these as two different objects or not, but I think it does. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4962: Pre-existing shared memory block is still in use
On Tue, Aug 4, 2009 at 12:49, Carlos Alonso wrote: > > The following bug has been logged online: > > Bug reference: 4962 > Logged by: Carlos Alonso > Email address: calo...@ictel.com > PostgreSQL version: 8.3.6 > Operating system: Windows XP Home Edition Version 2002 Service Pack 3 > Description: Pre-existing shared memory block is still in use > Details: > > 2009-08-01 15:36:08 CEST LOG: server process (PID 5892) was terminated by > exception 0xC142 > 2009-08-01 15:36:08 CEST HINT: See C include file "ntstatus.h" for a > description of the hexadecimal value. > 2009-08-01 15:36:08 CEST LOG: terminating any other active server > processes > 2009-08-01 15:36:08 CEST WARNING: terminating connection because of crash > of another server process > 2009-08-01 15:36:08 CEST DETAIL: The postmaster has commanded this server > process to roll back the current transaction and exit, because another > server process exited abnormally and possibly corrupted shared memory. > 2009-08-01 15:36:08 CEST HINT: In a moment you should be able to reconnect > to the database and repeat your command. > 2009-08-01 15:36:08 CEST WARNING: terminating connection because of crash > of another server process > 2009-08-01 15:36:08 CEST DETAIL: The postmaster has commanded this server > process to roll back the current transaction and exit, because another > server process exited abnormally and possibly corrupted shared memory. > 2009-08-01 15:36:08 CEST HINT: In a moment you should be able to reconnect > to the database and repeat your command. > [...] > 2009-08-01 15:36:08 CEST WARNING: terminating connection because of crash > of another server process > 2009-08-01 15:36:08 CEST DETAIL: The postmaster has commanded this server > process to roll back the current transaction and exit, because another > server process exited abnormally and possibly corrupted shared memory. > 2009-08-01 15:36:08 CEST HINT: In a moment you should be able to reconnect > to the database and repeat your command. > 2009-08-01 15:36:08 CEST FATAL: the database system is in recovery mode > 2009-08-01 15:36:08 CEST FATAL: the database system is in recovery mode > 2009-08-01 15:36:08 CEST LOG: all server processes terminated; > reinitializing > 2009-08-01 15:36:09 CEST FATAL: pre-existing shared memory block is still > in use > 2009-08-01 15:36:09 CEST HINT: Check if there are any old server processes > still running, and terminate them. > > There was no old server processes running. > This has happened twice in two weeks, the system was working for five > months. > > It is enough rebooting the computer in one case, and starting the postgres > service by windows's services.msc in the other. The standard question when this happens is - any antivirus or firewall software on the machine? They are known to cause just this type of issues. If so, try uninstalling them (not just disabling, but actually uninstalling is often required) and see if the problem goes away. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Mon, Aug 10, 2009 at 16:10, wader2 wrote: > Bruce Momjian wrote: >> >> I can't reproduce a crash here on BSD: >> >> $ pg_standby >> pg_standby: not enough command-line arguments >> >> Can you show us the command and the crash text? > > I guess this occurs on only windows (Japanese envionment?). > > C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe > > results no text on command line, Windows error dialog. > > AppName:pg_standby.exe AppVer:0.0.0.0 ModName:msvcr80.dll > ModVer:8.0.50727.762 Offset:91ad I have reproduced this. The problem is: (void) signal(SIGUSR1, sighandler); (void) signal(SIGINT, sighandler); /* deprecated, use SIGUSR1 */ None of these signals exist on WIN32. I think the only reason it compiles at all is that we bring in *some* of our signals emulation code, but certainly not all of it. If I just move those two lines into the #ifndef WIN32 block just around it, it compiles and doesn't crash on running-with-no-arguments. I haven't tried to actually use it though - can someone confirm if this will actually make pg_standby not work properly? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote: > Magnus Hagander writes: >> If I just move those two lines into the #ifndef WIN32 block just >> around it, it compiles and doesn't crash on running-with-no-arguments. >> I haven't tried to actually use it though - can someone confirm if >> this will actually make pg_standby not work properly? > > It would mean there's no way to trigger failover via signal. > > I think what we need is for pg_ctl to be able to send these signals... Those signals don't *exist* on Windows. The whole idea of cross-process signals don't *exist* on Windows. We emulate it in the main backend, by creating a background thread that sets a global variable. That is then polled in the CHECK_FOR_INTERRUPTS macro. pg_ctl is perfectly capable of sending these signals, but pg_standby can't receive them. We could implement the same type of check in pg_standby, but it requires something like CHECK_FOR_INTERRUPTS. And these interrupts won't, by default, cause any kind of interruption of the process. In the backend, we interrupt socket calls because we have the socket wrapper layer, and nothing else. I don't know how doable this would be in pg_standby - does it always block on a single thing where we could stick some win32 synchronization code? If it's a single, or limited, places we could implement something similar to the backend. But if we need to interrupt at arbitrary locations, that's just not possible. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
Yeah, the patch I think breaks things isn't included in 8.3.7 - it will be in 8.3.8 though... //Magnus On Wed, Aug 12, 2009 at 11:08, wader2 wrote: > I can't compile nor read source, but can tell you that > pg_standby.exe in 8.3.7 works fine. > > Magnus Hagander wrote: >> >> On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote: >>> >>> Magnus Hagander writes: >>>> >>>> If I just move those two lines into the #ifndef WIN32 block just >>>> around it, it compiles and doesn't crash on running-with-no-arguments. >>>> I haven't tried to actually use it though - can someone confirm if >>>> this will actually make pg_standby not work properly? >>> >>> It would mean there's no way to trigger failover via signal. >>> >>> I think what we need is for pg_ctl to be able to send these signals... >> >> Those signals don't *exist* on Windows. The whole idea of >> cross-process signals don't *exist* on Windows. >> >> We emulate it in the main backend, by creating a background thread >> that sets a global variable. That is then polled in the >> CHECK_FOR_INTERRUPTS macro. pg_ctl is perfectly capable of sending >> these signals, but pg_standby can't receive them. >> >> We could implement the same type of check in pg_standby, but it >> requires something like CHECK_FOR_INTERRUPTS. And these interrupts >> won't, by default, cause any kind of interruption of the process. In >> the backend, we interrupt socket calls because we have the socket >> wrapper layer, and nothing else. I don't know how doable this would be >> in pg_standby - does it always block on a single thing where we could >> stick some win32 synchronization code? If it's a single, or limited, >> places we could implement something similar to the backend. But if we >> need to interrupt at arbitrary locations, that's just not possible. >> >> > > -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Wed, Aug 12, 2009 at 19:08, Fujii Masao wrote: > Hi, > > On Tue, Aug 11, 2009 at 3:10 AM, Magnus Hagander wrote: >> I have reproduced this. The problem is: >> (void) signal(SIGUSR1, sighandler); >> (void) signal(SIGINT, sighandler); /* deprecated, use SIGUSR1 */ >> >> >> None of these signals exist on WIN32. I think the only reason it >> compiles at all is that we bring in *some* of our signals emulation >> code, but certainly not all of it. > > SIGINT has been used in pg_standby for a while (e.g., v8.3.7). I wonder > why this problem arises only in v8.4.0. Not sure. Potentially pure luck. SIGINT has never *worked*, though, it just hasn't crashed. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Wed, Aug 19, 2009 at 08:38, Fujii Masao wrote:
> On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagander wrote:
>> Not sure. Potentially pure luck. SIGINT has never *worked*, though, it
>> just hasn't crashed.
>
> OK.
>
>> We could implement the same type of check in pg_standby, but it
>> requires something like CHECK_FOR_INTERRUPTS. And these interrupts
>> won't, by default, cause any kind of interruption of the process. In
>> the backend, we interrupt socket calls because we have the socket
>> wrapper layer, and nothing else. I don't know how doable this would be
>> in pg_standby - does it always block on a single thing where we could
>> stick some win32 synchronization code? If it's a single, or limited,
>> places we could implement something similar to the backend. But if we
>> need to interrupt at arbitrary locations, that's just not possible.
>
> I think that CHECK_FOR_INTERRUPTS should be placed just before
> checking the flag 'signaled' which may be enabled by the signal handler.
> Here is the pseudo-code.
>
>
> {
> /* Check for trigger file or signal first */
> CheckForExternalTrigger();
> + #ifdef WIN32
> + CHECK_FOR_INTERRUPTS();
> + #endif /* WIN32 */
> if (signaled)
> {
> Failover = FastFailover;
>
It's going to take a lot more than that, really. I looked a bit more
at it, and I think the best way is to do a win32 specific thing all
the way, not just emulate signals. Given that we only have a couple of
signal() calls anyway. I think that's going to be much clearer in what
it does, and also a lot simpler code in the end. The reason we have
the full emulation layer is that we use signals all over the place in
the backend.
From what I can tell, we don't actually need to interrupt anything
other than the sleep call on line 810, because we only check for the
signaled=true state in that loop anyway. Can someone more
knowledgeable in the pg_standby code comment on that?
This would amount to fairly major surgery for pg_standby on Win32. Is
that something we'd want to backpatch, or do we want to backpatch just
the removal of the signal() calls which would amount to not supporting
signals in pg_standby on win32?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4994: Silent Installation
On Tue, Aug 18, 2009 at 19:38, Ali Al-Aswad wrote: > msiexec /i postgresql-8.2-int.msi /qn INTERNALLAUNCH=1 DOSERVICE=1 ^ This says 8.2. > The PostgreSQL Database Server 8.0 service on Local Computer started and > then stopped. Some services stop automatically if they have no work to do, > for example, the Performance Logs and Alerts service. ^ This says 8.0. It looks like you have two different versions installed that are somehow conflicting with each other. Possibly because they are trying to listen on the same port, or something like that. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Wed, Aug 19, 2009 at 11:45, Heikki Linnakangas wrote: > Magnus Hagander wrote: >> This would amount to fairly major surgery for pg_standby on Win32. Is >> that something we'd want to backpatch, or do we want to backpatch just >> the removal of the signal() calls which would amount to not supporting >> signals in pg_standby on win32? > > I think we should just remove the signals support for win32. The trigger > file method still works, and the signal method has always been a bit > iffy (it doesn't work when pg_standby isn't running, for example, which > happens between processing of each WAL file, because there's no process > to signal). Fair enough. > Is pg_standby killed correctly when postmaster dies? No idea. I can set up and env to test, but I don't have one ready. Anybody else have tried this? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5007: could not reattach to shared memory
On Tuesday, August 25, 2009, Craig Ringer wrote: > On Tue, 2009-08-25 at 05:44 +, Regina wrote: >> The following bug has been logged online: >> >> Bug reference: 5007 >> Logged by: Regina >> Email address: �...@pcorp.us >> PostgreSQL version: 8.3.6 >> Operating system: Windows 2008 Server Standard >> Description: could not reattach to shared memory >> Details: >> >> One of our clients is getting the following error in their PostgreSQL 8.3.6 >> logs in their http://ASP.NET application. This only happens if their >> application >> runs a long query (which they dump out to disk and disk size (ESRI >> shapefiles) is generally above 70 mb or more) when this fails. >> >> The error is below: >> FATAL: could not reattach to shared memory (key=232, addr=01DF): 487 >> %t WARNING: worker took too long to start; cancelled > > Search the -general mailing list archives for "reattach to shared > memory". The issue has been around for a while but until recently nobody > could reproduce it well enough to isolate it and test possible fixed. > You'll see some recent discussion and a proposed patch. > > Try upgrading to the latest version in the 8.3 series. If you still see > the problem please follow up here, or try the patch for the issuye > proposed on the pgsql-general list. The probable fix is not in a released version - it will be in the next one. Please try to upgrade to the latest and then replace postgres.exe with the one from http://blog.hagander.net ad let us know if it works in your situation. > >> In these cases their .NET app returns this error >> Exception of type 'System.OutOfMemoryException' was thrown > > That's probably a bug in their application caused by failure to properly > handle a connection problem. Yes, or possibly npgsql having the bug, though I haven't heard of it there. The stacktrace should probably tell you where - if not, a memory dump with the debugger. /Magnus -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5008: Server Startup Problem - When server is configured for SSL
On Tue, Aug 25, 2009 at 08:11, Jalaj Negi wrote: > > The following bug has been logged online: > > Bug reference: 5008 > Logged by: Jalaj Negi > Email address: jalajsinghn...@gmail.com > PostgreSQL version: 8.4.0 > Operating system: Windows XP with SP3 > Description: Server Startup Problem - When server is configured for > SSL > Details: > > I am running PostgreSQL version 8.4.0 on Windows XP machine with SP3. I > installed using Win32 Installer Package and the server runs as a service and > a service account was automatically created by the Win32 installer package > during server installation. > > With default configuration the server was running fine and took minimal time > to start up (2-3 seconds). But when I configured server for SSL and > restarted server it took long time to start up (3-4 minutes) and displayed > the following startup message. > > > Startup Message > = > The PostgreSQL Server 8.4 service is > starting... > .. > The PostgreSQL Server 8.4 service could not be started. > > The service did not report an error. > > More help is available by typing NET HELPMSG 3534. > > The start command returned an error (2) > > Press to continue... > = > > > Exact Steps > = > 1) Stopped the server. > > 2) Made following changes in configuration files for enabling SSL support. > > In pg_hba.conf I have only following one entry - > hostssl all all 127.0.0.1/32 md5 clientcert=1 > > In postgresql.conf I made following changes - > ssl = on > ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH' > > Added server.crt, server.key, root.crt, root.crl in servers data directory. > > 3) Started the server. > = > > > Few Observations > = > 1) When server starts with default configuration (without SSL configuration > changes) following process are created and running in system - pg_ctl.exe (1 > instance), postgres.exe (6 instances). > > 2) When server starts with SSL configuration changes following process are > created and running in system - postgres.exe (6 instances). This time > pg_ctl.exe process is absent. > > 3) Server starts properly when "clientcert=1" is removed from pg_hba.conf > file. But if we want server to request client certificates we cant remove > clientcert parameter from pg_hba.conf file. What's in the log? Check both the PostgreSQL logfile and the Windows eventlog. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
