Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-12-25 Thread David Rowley
On 25 December 2014 at 18:27, Noah Misch n...@leadboat.com wrote: On Thu, Dec 25, 2014 at 03:55:02PM +1300, David Rowley wrote: f6dc6dd seems to have broken vcregress check for me: FATAL: no pg_hba.conf entry for host ::1, user David, database postgres ... FATAL: no pg_hba.conf

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-12-25 Thread Noah Misch
On Thu, Dec 25, 2014 at 11:35:31PM +1300, David Rowley wrote: On 25 December 2014 at 18:27, Noah Misch n...@leadboat.com wrote: This needs to be conditional on whether the platform supports IPv6, like we do in setup_config(). The attached patch works on these configurations: 64-bit

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-12-24 Thread David Rowley
On 30 November 2014 at 15:02, Noah Misch n...@leadboat.com wrote: On Sun, Sep 21, 2014 at 02:31:15AM -0400, Noah Misch wrote: It then dawned on me that every Windows build of PostgreSQL already has a way to limit connections to a particular OS user. SSPI authentication is essentially the

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-12-24 Thread Michael Paquier
On Thu, Dec 25, 2014 at 11:55 AM, David Rowley dgrowle...@gmail.com wrote: f6dc6dd seems to have broken vcregress check for me: Having a look at the pg_hba.conf that's been generated by pgregress, it looks like it only adds a line for IPv4 addresses. Indeed. I can see this problem as well on my

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-12-24 Thread Noah Misch
On Thu, Dec 25, 2014 at 03:55:02PM +1300, David Rowley wrote: f6dc6dd seems to have broken vcregress check for me: FATAL: no pg_hba.conf entry for host ::1, user David, database postgres ... FATAL: no pg_hba.conf entry for host ::1, user David, database postgres Thanks. I bet this is

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-11-29 Thread Noah Misch
On Sun, Sep 21, 2014 at 02:31:15AM -0400, Noah Misch wrote: It then dawned on me that every Windows build of PostgreSQL already has a way to limit connections to a particular OS user. SSPI authentication is essentially the Windows equivalent of peer authentication. A brief trial thereof

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-09-21 Thread Noah Misch
On Sun, Mar 02, 2014 at 11:36:41PM +0100, Magnus Hagander wrote: On Sun, Mar 2, 2014 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Noah Misch n...@leadboat.com writes: One option that would simplify things is to fix only non-Windows in the back branches, via socket protection, and

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-14 Thread Christoph Berg
Re: Noah Misch 2014-07-12 20140712170151.ga1985...@tornado.leadboat.com Thanks. Preliminary questions: +#ifdef HAVE_UNIX_SOCKETS +/* make_temp_sockdir() is invoked at most twice from pg_upgrade.c via get_sock_dir() */ +#define MAX_TEMPDIRS 2 +static int n_tempdirs = 0; /* actual

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-12 Thread Noah Misch
On Fri, Jul 11, 2014 at 12:40:09PM +0300, Christoph Berg wrote: I believe pg_upgrade itself still needs a fix. While it's not a security problem to put the socket in $CWD while upgrading (it is using -c unix_socket_permissions=0700), this behavior is pretty unexpected, and

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-11 Thread Christoph Berg
Re: Bruce Momjian 2014-07-08 20140708202114.gd9...@momjian.us I believe pg_upgrade itself still needs a fix. While it's not a security problem to put the socket in $CWD while upgrading (it is using -c unix_socket_permissions=0700), this behavior is pretty unexpected, and does fail

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-11 Thread Christoph Berg
Re: To Bruce Momjian 2014-07-11 20140711093923.ga3...@msg.df7cb.de Re: Bruce Momjian 2014-07-08 20140708202114.gd9...@momjian.us I believe pg_upgrade itself still needs a fix. While it's not a security problem to put the socket in $CWD while upgrading (it is using -c

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-08 Thread Christoph Berg
Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com Here's an update that places the socket in a temporary subdirectory of /tmp. The first attached patch adds NetBSD mkdtemp() to libpgport. The second, principal, patch uses mkdtemp() to implement this design in pg_regress.

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-08 Thread Noah Misch
On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote: Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com Here's an update that places the socket in a temporary subdirectory of /tmp. The first attached patch adds NetBSD mkdtemp() to libpgport. The second,

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-08 Thread Christoph Berg
Re: Noah Misch 2014-07-08 20140708174125.ga1884...@tornado.leadboat.com On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote: Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com Here's an update that places the socket in a temporary subdirectory of /tmp.

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-07-08 Thread Bruce Momjian
On Tue, Jul 8, 2014 at 08:21:48PM +0200, Christoph Berg wrote: Re: Noah Misch 2014-07-08 20140708174125.ga1884...@tornado.leadboat.com On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote: Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com Here's an update

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-06-08 Thread Noah Misch
On Sun, Mar 23, 2014 at 07:04:20PM -0400, Noah Misch wrote: On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote: On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: I'm inclined to suggest that we should put the socket under $CWD by default, but provide some way for the user

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-04-04 Thread YAMAMOTO Takashi
On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote: Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD:

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-04-04 Thread Tom Lane
y...@netbsd.org (YAMAMOTO Takashi) writes: On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote: openvswitch has some tricks to overcome the socket path length limitation using symlink. (or procfs where available) iirc these were introduced for debian builds which use deep CWD.

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-04-03 Thread YAMAMOTO Takashi
Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD: http://www.postgresql.org/message-id/flat/20121129223632.ga15...@tornado.leadboat.com openvswitch has some tricks to overcome the socket path

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-04-03 Thread Noah Misch
On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote: Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD:

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-31 Thread Robert Haas
On Sun, Mar 30, 2014 at 3:52 PM, Christoph Berg c...@df7cb.de wrote: Re: Noah Misch 2014-03-30 20140330014531.ge170...@tornado.leadboat.com On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote: Fwiw, to relocate the pg_regress socket dir, there is already the possibility to run

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-31 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sun, Mar 30, 2014 at 3:52 PM, Christoph Berg c...@df7cb.de wrote: Oh, right. There's this other patch which apparently works so well that I already forgot it's there: Enable pg_regress --host=/path/to/socket:

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-31 Thread Christoph Berg
Re: Tom Lane 2014-03-31 22183.1396293...@sss.pgh.pa.us Enable pg_regress --host=/path/to/socket: https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-9.4/trunk/view/head:/debian/patches/60-pg_regress_socketdir.patch Wasn't this patch submitted for inclusion in PostgreSQL at

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-31 Thread Robert Haas
On Mon, Mar 31, 2014 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sun, Mar 30, 2014 at 3:52 PM, Christoph Berg c...@df7cb.de wrote: Oh, right. There's this other patch which apparently works so well that I already forgot it's there: Enable

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-30 Thread Christoph Berg
Re: Noah Misch 2014-03-30 20140330014531.ge170...@tornado.leadboat.com On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote: Fwiw, to relocate the pg_regress socket dir, there is already the possibility to run make check EXTRA_REGRESS_OPTS=--host=/tmp. (With the pending fix I sent

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-29 Thread Christoph Berg
Re: Noah Misch 2014-03-24 20140323230420.ga4139...@tornado.leadboat.com On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote: On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: I'm inclined to suggest that we should put the socket under $CWD by default, but provide some way

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-29 Thread Noah Misch
On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote: Fwiw, to relocate the pg_regress socket dir, there is already the possibility to run make check EXTRA_REGRESS_OPTS=--host=/tmp. (With the pending fix I sent yesterday to extend this to contrib/test_decoding.) That doesn't work for

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-23 Thread Noah Misch
On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote: On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: I'm inclined to suggest that we should put the socket under $CWD by default, but provide some way for the user to override that choice. If they want to put it in /tmp, it's

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-23 Thread Noah Misch
On Sun, Mar 23, 2014 at 07:04:20PM -0400, Noah Misch wrote: On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote: On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: I'm inclined to suggest that we should put the socket under $CWD by default, but provide some way for the user

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-06 Thread Tom Lane
Noah Misch n...@leadboat.com writes: Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD: I'm not thrilled with that; it's totally insecure on platforms where /tmp isn't sticky, so it doesn't seem

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-06 Thread Noah Misch
On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD: I'm not thrilled with that; it's totally

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-06 Thread Tom Lane
Noah Misch n...@leadboat.com writes: On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: I'm inclined to suggest that we should put the socket under $CWD by default, but provide some way for the user to override that choice. If they want to put it in /tmp, it's on their head as to how

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-05 Thread Noah Misch
On Tue, Mar 04, 2014 at 07:10:27PM -0500, Bruce Momjian wrote: On Sat, Mar 1, 2014 at 01:35:45PM -0500, Noah Misch wrote: Having that said, I can appreciate the value of tightening the socket mode for a bit of *extra* safety: --- a/src/test/regress/pg_regress.c +++

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-04 Thread Noah Misch
On Sun, Mar 02, 2014 at 05:38:38PM -0500, Noah Misch wrote: Concerning the immediate fix for non-Windows systems, does any modern system ignore modes of Unix domain sockets? It appears to be a long-fixed problem: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-1402

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-04 Thread Noah Misch
On Mon, Mar 03, 2014 at 08:15:41PM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: On Mon, Mar 03, 2014 at 01:29:00AM -0500, Tom Lane wrote: What I was envisioning was that we'd be relying on the permissions of the containing directory to keep out bad guys. Permissions on the

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-04 Thread Bruce Momjian
On Sat, Mar 1, 2014 at 01:35:45PM -0500, Noah Misch wrote: Having that said, I can appreciate the value of tightening the socket mode for a bit of *extra* safety: --- a/src/test/regress/pg_regress.c +++ b/src/test/regress/pg_regress.c @@ -2299,4 +2299,5 @@ regression_main(int argc, char

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-03 Thread Andrew Dunstan
On 03/03/2014 02:00 AM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: The only way I can see this being of real use to an attacker is if they could use this exploit to create a wormed version of PostgresQL on the target build system. Is that possible? It's theoretically possible,

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-03 Thread Noah Misch
On Mon, Mar 03, 2014 at 01:29:00AM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: Concerning the immediate fix for non-Windows systems, does any modern system ignore modes of Unix domain sockets? It appears to be a long-fixed problem: What I was envisioning was that we'd be

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-03 Thread Tom Lane
Noah Misch n...@leadboat.com writes: On Mon, Mar 03, 2014 at 01:29:00AM -0500, Tom Lane wrote: What I was envisioning was that we'd be relying on the permissions of the containing directory to keep out bad guys. Permissions on the socket itself might be sufficient, but what does it save us to

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-03 Thread Tom Lane
I wrote: Placing the socket anywhere besides the default location will require setting PGHOST anyway, so I don't see that this argument holds much water. The cleanup aspect is likewise not that exciting; pg_regress creates a lot of stuff it doesn't remove. There's another point here, if you

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Magnus Hagander
On Sun, Mar 2, 2014 at 6:20 AM, Noah Misch n...@leadboat.com wrote: On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote: On 03/01/2014 05:10 PM, Tom Lane wrote: One other thought here: is it actually reasonable to expend a lot of effort on the Windows case? I'm not aware that

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Stephen Frost
* Dave Page (dp...@pgadmin.org) wrote: It's not that rare in my experience - certainly there are far more single user installations, but Terminal Server configurations are common for deploying apps Citrix-style or VDI. The one and only Windows server maintained by the EDB infrastructure

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Tom Lane
Noah Misch n...@leadboat.com writes: One option that would simplify things is to fix only non-Windows in the back branches, via socket protection, and fix Windows in HEAD only. We could even do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes. +1 for that solution, if

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread james
On 02/03/2014 15:30, Magnus Hagander wrote: Terminal Services have definitely become more common over time, but with faster and cheaper virtualization, a lot of people have switched to that instead, which would remove the problem of course. I wonder how common it actually is, though, to

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Andrew Dunstan
On 03/02/2014 01:27 PM, Tom Lane wrote: Also, to what extent does any of this affect buildfarm animals? Whatever we do for make check will presumably make those tests safe for them, but how are the postmasters they test under make installcheck set up? Nothing special. bin/initdb -U

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Stephen Frost
* james (ja...@mansionfamily.plus.com) wrote: Well, the banks I've contracted at recently are all rather keen on virtual desktops for developers, and some of those are terminal services. We're a headache, and packaging up all the things we need is a pain, so there is some mileage in buying

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Josh Berkus
On 03/02/2014 12:17 PM, Stephen Frost wrote: The issue here is about how much effort to go to in order to secure the PostgreSQL system that is started up to do the regression tests. It's already set up to only listen on localhost and will run with only the privileges of the user running the

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Stephen Frost
* Josh Berkus (j...@agliodbs.com) wrote: The only way I can see this being of real use to an attacker is if they could use this exploit to create a wormed version of PostgresQL on the target build system. Is that possible? I don't see why it wouldn't be- once the attacker is on the box as any

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Magnus Hagander
On Sun, Mar 2, 2014 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Noah Misch n...@leadboat.com writes: One option that would simplify things is to fix only non-Windows in the back branches, via socket protection, and fix Windows in HEAD only. We could even do so by extending

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Noah Misch
On Sun, Mar 02, 2014 at 01:27:18PM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: One option that would simplify things is to fix only non-Windows in the back branches, via socket protection, and fix Windows in HEAD only. We could even do so by extending HAVE_UNIX_SOCKETS

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Tom Lane
Noah Misch n...@leadboat.com writes: Concerning the immediate fix for non-Windows systems, does any modern system ignore modes of Unix domain sockets? It appears to be a long-fixed problem: What I was envisioning was that we'd be relying on the permissions of the containing directory to keep

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Tom Lane
Josh Berkus j...@agliodbs.com writes: The only way I can see this being of real use to an attacker is if they could use this exploit to create a wormed version of PostgresQL on the target build system. Is that possible? It's theoretically possible, since having broken into the build user's

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-02 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Noah Misch n...@leadboat.com writes: Concerning the immediate fix for non-Windows systems, does any modern system ignore modes of Unix domain sockets? It appears to be a long-fixed problem: What I was envisioning was that we'd be relying on the

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Alvaro Herrera
I didn't check the patch in detail, but it seems to me that both the encode stuff as well as pgrand belong in src/common rather than src/port. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Noah Misch
On Sat, Mar 01, 2014 at 12:48:08PM -0300, Alvaro Herrera wrote: I didn't check the patch in detail, but it seems to me that both the encode stuff as well as pgrand belong in src/common rather than src/port. Since src/common exists only in 9.3 and up, that would mean putting them in different

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Tom Lane
Noah Misch n...@leadboat.com writes: As announced with last week's releases, use of trust authentication in the make check temporary database cluster makes it straightforward to hijack the OS user account involved. The prerequisite is another user account on the same system. The solution we

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Andrew Dunstan
On 03/01/2014 12:29 PM, Tom Lane wrote: In the case of Unix systems, there is a *far* simpler and more portable solution technique, which is to tell the test postmaster to put its socket in some non-world-accessible directory created by the test scaffolding. +1 - I'm all for KISS. Of

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Magnus Hagander
On Sat, Mar 1, 2014 at 7:09 PM, Andrew Dunstan and...@dunslane.net wrote: On 03/01/2014 12:29 PM, Tom Lane wrote: In the case of Unix systems, there is a *far* simpler and more portable solution technique, which is to tell the test postmaster to put its socket in some non-world-accessible

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Noah Misch
On Sat, Mar 01, 2014 at 12:29:38PM -0500, Tom Lane wrote: There are two big problems with the lets-generate-a-random-password approach. Noah acknowledged the portability issue of possibly not having a strong entropy source available. The other issue though is whether doing this doesn't

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: In the case of Unix systems, there is a *far* simpler and more portable solution technique, which is to tell the test postmaster to put its socket in some non-world-accessible directory created by the test scaffolding. Yes, yes, yes. Of course that

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: For a one-off password used locally only, we could also consider just using a guid, and generate it using http://msdn.microsoft.com/en-us/library/windows/desktop/aa379205(v=vs.85).aspx. Not sure if that API is intended to create an unpredictable

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Andrew Dunstan
On 03/01/2014 05:10 PM, Tom Lane wrote: One other thought here: is it actually reasonable to expend a lot of effort on the Windows case? I'm not aware that people normally expect a Windows box to have multiple users at all, let alone non-mutually-trusting users. As Stephen said, it's

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 03/01/2014 05:10 PM, Tom Lane wrote: BTW, a different problem with the proposed patch is that it changes some test cases in ecpg and contrib/dblink, apparently to avoid session reconnections. That seems likely to me to be losing test coverage.

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Noah Misch
On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote: On 03/01/2014 05:10 PM, Tom Lane wrote: One other thought here: is it actually reasonable to expend a lot of effort on the Windows case? I'm not aware that people normally expect a Windows box to have multiple users at all, let

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Noah Misch
On Sat, Mar 01, 2014 at 09:43:19PM -0500, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 03/01/2014 05:10 PM, Tom Lane wrote: BTW, a different problem with the proposed patch is that it changes some test cases in ecpg and contrib/dblink, apparently to avoid session

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-03-01 Thread Dave Page
On 2 Mar 2014, at 05:20, Noah Misch n...@leadboat.com wrote: On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote: On 03/01/2014 05:10 PM, Tom Lane wrote: One other thought here: is it actually reasonable to expend a lot of effort on the Windows case? I'm not aware that people