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
* 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 cle
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 tha
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 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 t
* 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
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 b
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 distracte
"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 t
* 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
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
"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
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
"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 w
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 ..
"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 initd
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.
> Lik
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.
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 th
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 ./configu
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
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 a
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 ne
On Sat, Jun 23, 2007 at 12:02:43PM -0400, 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
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 doe
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 existi
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
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,
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 wh
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 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 passwo
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 me
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 socke
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 complaint
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 whe
* 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
> br
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 pas
> >> 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.
>
> Practical
"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
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
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 behavio
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 sec
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 o
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
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 P
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."
http://www.securityfocus.com/
47 matches
Mail list logo
