Patch based on recent -hackers discussions, it removes usage from public, and
adds a note to the documentation about why this is neccessary.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: contrib/dblink/dblink.sql.in
Robert Treat wrote:
Patch based on recent -hackers discussions, it removes usage from public, and
adds a note to the documentation about why this is neccessary.
I agree with the fix as the simplest and most sensible approach, and in
general with the doc change, but I'm not inclined to refere
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Robert Treat wrote:
>> Patch based on recent -hackers discussions, it removes usage from public, and
>> adds a note to the documentation about why this is neccessary.
>>
>
> I agree with the fix as the simplest and most sensible approach, and in
> genera
On Sunday 01 July 2007 13:15, Gregory Stark wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > Robert Treat wrote:
> >> Patch based on recent -hackers discussions, it removes usage from
> >> public, and adds a note to the documentation about why this is
> >> neccessary.
> >
> > I agree with the
Robert Treat <[EMAIL PROTECTED]> writes:
> Did you mean s/trust/ident/g, otherwise I don't think I understand the
> above...
Both trust and ident local auth are sources of risk for this, although
ident is particularly nasty since the DBA probably thinks he's being
secure.
For that matter, I'm no
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> Did you mean s/trust/ident/g, otherwise I don't think I understand the
>> above...
>
> Both trust and ident local auth are sources of risk for this, although
> ident is particularly nasty since the DBA probably thinks he's being
> secu
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I don't see a reason to reject the patch. All the arguments about
why
> > using C++ in the backend is ill-advised are well-taken, but the
patch
> > does *not* require "making a real commitment to making C++ usable as
> a
> > backend extension language"
"Robert Treat" <[EMAIL PROTECTED]> writes:
>> In particular Postgres's "trust" authentication is one such system. It
>> authenticates connecting users based on the unix userid of the process
>> forming the connection. In typical configurations any user who is granted
>> execute access to dblin
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> LDAP is not affected - it requires the user to enter a password. Same
> would be for any PAM plugins that actually require the user to enter a
> password, I think.
Agreed.
> Kerberos is not affected either, because the server does not get a copy
> of
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> Kerberos is not affected either, because the server does not get a copy
>> of the ticket. In theory it could be affected if the server requested a
>> delegation enabled ticket, and exported it so it could be
Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>>> Kerberos is not affected either, because the server does not get a copy
>>> of the ticket. In theory it could be affected if the server requested a
>>> delegation enabled ticket, and expo
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
Did you mean s/trust/ident/g, otherwise I don't think I understand the
above...
Both trust and ident local auth are sources of risk for this, although
ident is particularly nasty since the DBA probably thinks he's being
secure.
For that
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Kerberos is not affected either, because the server does not get a copy
of the ticket. In theory it could be affected if the server requested a
delegation enabled ticket, and exported it so it
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Would it be sensible to change dblink so that unless invoked by a
>> superuser, it fails any connection attempt in which no password is
>> demanded? I am not sure that this is possible without changes to libpq;
>> but ignoring implementat
On Sat, Jun 30, 2007 at 01:48:51AM -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > For the ALTER SEQUENCE case, I think it's also a little weird to
> > have an ALTER SEQUENCE command that modifies some of the
> > properties of a sequence, but not the sequence's name. While that
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Would it be sensible to change dblink so that unless invoked by a
superuser, it fails any connection attempt in which no password is
demanded? I am not sure that this is possible without changes to libpq;
but ignoring imple
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Would it be sensible to change dblink so that unless invoked by a
>>> superuser, it fails any connection attempt in which no password is
>>> demanded? I am not sure that this is possible without changes to libpq;
>>> b
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> bool PQconnectionUsedPassword(const PGconn *conn);
> Maybe PQconnectionUsedAuthToken() to mean "data supplied by the client",
> including other potential future mechanisms?
Well, that'd not solve the pre-existing problem of how to tell
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Hmm. It would be better if it never actually completed an authentication
> in the first place, but I don't see how we can do that given how the
> protocol works.
> We could add a connection string parameter that disables it, but that
> doesn't really he
On Sunday 01 July 2007 16:03, Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> Would it be sensible to change dblink so that unless invoked by a
> >>> superuser, it fails any connection attempt in which no password is
> >>> demanded? I am no
Robert Treat <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I like this approach better than removing public execute privileges
>> on the functions, for two reasons:
> I think this will break backwards compatability though.
Well, revoking public execute will break backwards compatibility too.
Robert Treat wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
How so -- it is fundamentally no different than dblink, which is C
language (also untrusted).
I think
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I like this approach better than removing public execute privileges
> on the functions, for two reasons:
>
> * A routine minor version update would install the security fix into
> existing installations, without need for any DBA intervention.
>
> * It does
Joe Conway wrote:
Robert Treat wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
How so -- it is fundamentally no different than dblink, which is C
language (also unt
Gregory Stark <[EMAIL PROTECTED]> writes:
> I think there are two problems with this:
> a) dblink still shouldn't allow arbitrary users to open arbitrary tcp/ip
>sockets or unix sockets from the server. That's still a security threat
>even if we close Postgres's vulnerability to it.
The o
"Chuck McDevitt" <[EMAIL PROTECTED]> writes:
> I've tried compiling the entire backend in C++ in the past, just to see
> how much of a problem it would be.
Just for fun, I tried that experiment tonight on CVS HEAD: I used g++
from a current Fedora 6 installation (g++ Red Hat 4.1.1-51) instead of
t
On Sunday 01 July 2007 17:59, Joe Conway wrote:
> Joe Conway wrote:
> > Robert Treat wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> >>>
> >>> Well certainly dbi-link has the exact same issue.
> >>
> >> dbi-link only works in plperlu, so you've already decided your superuser
> >> only.
> >
>
On Sun, 2007-01-07 at 12:55 -0700, David Fetter wrote:
> Here's a new patch + file. This one allows ALTER [SEQUENCE | VIEW] to
> work only on the respective database objects, but permits the old
> ALTER TABLE syntax.
How about taking a look at the more thorough documentation updates Tom
suggested
28 matches
Mail list logo
