On Tue, 26 Jun 2007, Andrew Dunstan wrote:
Jeremy Drake wrote:
2. If you cannot tell what process is connecting on a local socket (which
I suspect you cannot portably),
See ident_unix() in hba.c.
It might not be 100% portable but I think it's fairly close for platforms
that actually
Stephen Frost wrote:
* Florian Pflug ([EMAIL PROTECTED]) wrote:
Gregory Stark wrote:
All that really has to happen is that dblink should by default not be
callable
by any user other than Postgres. DBAs should be required to manually run
GRANT EXECUTE ON dblink_connect(text) TO public; if
* Florian Pflug ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Uh, have the admin create appropriate views.
I meant letting them use it to connect to abitrary databases and hosts, not
executing only predefined quries. My wording wasn't clear in that regard,
though.
Perhaps I wasn't clear.
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
The normal build process for any open-source package is
./configure
make
sudo make install
... now what? OK, time to read the manual ...
Since they
Andrew Hammond [EMAIL PROTECTED] writes:
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
+1 on having such a discussion in the manual (someone else suggested
that already IIRC). But I'm not seeing what a configure flag brings
to the party.
Like Andrew Sullivan said above, if we want to
On Tue, Jun 26, 2007 at 03:08:59PM -0400, Tom Lane wrote:
It still wouldn't make us secure by default. Not unless you propose
to actually change the default.
Perhaps I wasn't clear enough, but the suggestion I made (for
something I actually don't care about, I hasten to add again) was
that the
Tom Lane [EMAIL PROTECTED] writes:
As for inside connections, secure is still largely dependent on what your
threat model is.
Indeed I think closing Postgres to access based on the unix userid of the
connecting user is the wrong threat model. That's basically saying you don't
trust the unix
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have gotten distracted :-(
The only problem with
* Tom Lane ([EMAIL PROTECTED]) wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have gotten
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have gotten distracted
Gregory Stark wrote:
All that really has to happen is that dblink should by default not be callable
by any user other than Postgres. DBAs should be required to manually run
GRANT EXECUTE ON dblink_connect(text) TO public; if that's what he wants.
That serves the purpose of making PG secure by
* Florian Pflug ([EMAIL PROTECTED]) wrote:
Gregory Stark wrote:
All that really has to happen is that dblink should by default not be
callable
by any user other than Postgres. DBAs should be required to manually run
GRANT EXECUTE ON dblink_connect(text) TO public; if that's what he wants.
On Tue, 26 Jun 2007, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have
Jeremy Drake wrote:
2. If you cannot tell what process is connecting on a local socket (which
I suspect you cannot portably),
See ident_unix() in hba.c.
It might not be 100% portable but I think it's fairly close for platforms
that actually have unix sockets.
cheers
andrew
On Sat, Jun 23, 2007 at 06:14:23PM +0200, Magnus Hagander wrote:
The benefit would be that PostgreSQL would be secure by default. Which
we are *not* today.
To achieve the secure by default feature that you want (and I like
the scare-quotes -- I agree with those that think this adds no real
Andrew Sullivan [EMAIL PROTECTED] writes:
To achieve the secure by default feature that you want (and I like
the scare-quotes -- I agree with those that think this adds no real
security, but I think you're right to worry about the perception
angle in this case), why not have a ./configure
On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.
Like I said, I don't actually think it _is_ better. But it would
solve the problem that some people
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.
Like I said, I don't actually think it _is_ better. But it
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.
Like I said,
Andrew Hammond [EMAIL PROTECTED] writes:
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
The normal build process for any open-source package is
./configure
make
sudo make install
... now what? OK, time to read the manual ...
Since they presumably don't know about initdb yet, yeah, I
Steve Atkins [EMAIL PROTECTED] writes:
On Jun 23, 2007, at 11:03 AM, Magnus Hagander wrote:
Out of curiosity, how do other databases deal with this?
MySQL installs with an empty root password for access from
localhost or the machines own IP address. It also installs an
account with network
Tom Lane wrote:
Steve Atkins [EMAIL PROTECTED] writes:
On Jun 23, 2007, at 11:03 AM, Magnus Hagander wrote:
Out of curiosity, how do other databases deal with this?
MySQL installs with an empty root password for access from
localhost or the machines own IP address. It
Magnus Hagander wrote:
That won't help; that would introduce the embarrassment of
having a known default password.
No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs initdb, it would
prompt for the postgres user password.
Practically
Magnus Hagander wrote:
Magnus Hagander wrote:
That won't help; that would introduce the embarrassment of
having a known default password.
No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs initdb, it would
prompt for the
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type.
I'll object if no one else does: this will break existing
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really
Magnus Hagander [EMAIL PROTECTED] writes:
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it
Andrew Dunstan wrote:
Magnus Hagander wrote:
Magnus Hagander wrote:
That won't help; that would introduce the embarrassment of
having a known default password.
No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs
On Jun 23, 2007, at 11:03 AM, Magnus Hagander wrote:
I would also argue that trust auth is not such an evil option that we
mustn't allow it to be the default. On a single-user machine it's
actually perfectly sane, seeing that we don't allow TCP connections
by default.
Is there really such
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type.
I'll object if no one else does: this will break
On Jun 19, 2007, at 1:27 PM, Josh Berkus wrote:
I know there's issues with using ident sameuser via TCP, but what
about for filesystem socket connections?
Not all OSes support ident ... Solaris and OpenBSD for two, don't,
because
they see ident as insecure.
What about the unix domain
Jim Nasby [EMAIL PROTECTED] writes:
On Jun 19, 2007, at 1:27 PM, Josh Berkus wrote:
Not all OSes support ident ... Solaris and OpenBSD for two, don't,
because they see ident as insecure.
What about the unix domain socket, though? AFAIK that doesn't rely on
ident but some other method...
Jim,
I know there's issues with using ident sameuser via TCP, but what
about for filesystem socket connections?
Not all OSes support ident ... Solaris and OpenBSD for two, don't, because
they see ident as insecure.
We switched the default to trust localhost only after many, many complaints
Joshua D. Drake [EMAIL PROTECTED] writes:
Christopher Browne wrote:
That won't help; that would introduce the embarrassment of having a
known default password.
No it wouldn't unless the packagers set it up to do that. My point is
that when a packager (or source) runs initdb, it would prompt
That won't help; that would introduce the embarrassment of having a
known default password.
No it wouldn't unless the packagers set it up to do that. My point is
that when a packager (or source) runs initdb, it would prompt for the
postgres user password.
Practically every
Hi,
On Mon, 2007-06-18 at 01:58 -0400, Tom Lane wrote:
Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.
Also, from RPM perspective: RPMs are *not* interactive, and will *never*
be. So we cannot ask user a
* Jeremy Drake ([EMAIL PROTECTED]) wrote:
The crux of this seems to be two-fold:
1. If dblink is installed, an untrusted user could use it to gain
privileges, either using trust/ident auth (you have a superuser named
after the account the postmaster is runing as), or can be scripted to
brute
On Jun 18, 2007, at 12:58 AM, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Christopher Browne wrote:
That won't help; that would introduce the embarrassment of
having a
known default password.
No it wouldn't unless the packagers set it up to do that. My point is
that when a
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
A message entitled Having Fun With PostgreSQL was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of
The world rejoiced as [EMAIL PROTECTED] (Joshua D. Drake) wrote:
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
A message entitled Having Fun With PostgreSQL was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems
Christopher Browne wrote:
The world rejoiced as [EMAIL PROTECTED] (Joshua D. Drake) wrote:
Tom Lane wrote:
We've debated #1 before, and a lot of repackagers change it, but I
don't really feel a strong urge to change it in the source distro.
As for #2, that's not a bug, it's intended
Christopher Browne [EMAIL PROTECTED] writes:
The world rejoiced as [EMAIL PROTECTED] (Joshua D. Drake) wrote:
On #1, the fact that we allow trust as default is embarrassing.
This is a case where it takes careful thought to grasp whether there
is a problem or not.
If all we do is to shift the
A message entitled Having Fun With PostgreSQL was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of Stupid PostgreSQL Tricks.
Michael Fuhr [EMAIL PROTECTED] writes:
A message entitled Having Fun With PostgreSQL was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of Stupid
On Sat, 16 Jun 2007, Michael Fuhr wrote:
A message entitled Having Fun With PostgreSQL was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of Stupid
46 matches
Mail list logo
