Joe Conway <[EMAIL PROTECTED]> writes:
> Tommy Gildseth wrote:
>> I'm not quite sure I fully understand the consequence of this change.
>> Does it basically mean that it's not possible to use .pgpass with dblink
>> for authentication?
> It only applies to 8.4 (which is not yet released) and beyo
Tommy Gildseth wrote:
Tom Lane wrote:
Okay. I just committed the patch without that change, but I'll go back
and add it.
I'm not quite sure I fully understand the consequence of this change.
Does it basically mean that it's not possible to use .pgpass with dblink
for authentication?
It on
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
No, the test to see if the server actually *asked* for the password is
the important part at that end.
Oh, I see that now. So yes, as far as I can tell, password_from_string
is not used for anything anymore and should be
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, the test to see if the server actually *asked* for the password is
>> the important part at that end.
> Oh, I see that now. So yes, as far as I can tell, password_from_string
> is not used for anything anymore and should be removed.
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What do you think about getting rid of the password_from_string state
variable? It was always a bit of a kluge, and we don't seem to need
it anymore with this approach.
It is still used in PQconnectionUsedPassword(). That
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What do you think about getting rid of the password_from_string state
>> variable? It was always a bit of a kluge, and we don't seem to need
>> it anymore with this approach.
> It is still used in PQconnectionUsedPassword(). That is stil
Tom Lane wrote:
What do you think about getting rid of the password_from_string state
variable? It was always a bit of a kluge, and we don't seem to need
it anymore with this approach.
It is still used in PQconnectionUsedPassword(). That is still needed to
prevent a non-superuser from loggin
Joe Conway <[EMAIL PROTECTED]> writes:
> Maybe better:
> static PQconninfoOption *
> conninfo_parse(const char *conninfo, PQExpBuffer errorMessage,
> bool fill_defaults, bool *password_from_string)
I'm thinking a separate conninfo_fill_defaults function is better,
though it's not
Joe Conway wrote:
Tom Lane wrote:
Refactoring doesn't seem like an easy way to fix this, because of the
problem that the behavior of pulling up defaults is part of the API
specification for PQconndefaults().
Thoughts?
Hmm, I could have sworn I looked for that, and saw it elsewhere. Anyway,
y
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Refactoring doesn't seem like an easy way to fix this, because of the
>> problem that the behavior of pulling up defaults is part of the API
>> specification for PQconndefaults().
> conninfo_parse() is presently only called from a few pla
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
New patch attached.
erm ... wait a minute. This approach doesn't actually solve the problem
at all, because conninfo_parse is responsible for filling in various
sorts of default values. In particular it would happily pull a password
from
Joe Conway <[EMAIL PROTECTED]> writes:
> New patch attached.
erm ... wait a minute. This approach doesn't actually solve the problem
at all, because conninfo_parse is responsible for filling in various
sorts of default values. In particular it would happily pull a password
from the services file
Joe Conway <[EMAIL PROTECTED]> writes:
> New patch attached.
This is close, but you're failing to guard against a few out-of-memory
corner cases (and now that I look, PQconndefaults() is too). The libpq
documentation needs more work than this, too.
I'll make a cleanup pass and commit.
BTW, I'm
Tom Lane wrote:
Yeah. We could make one further refinement: callers that don't care
about acquiring an error string can pass NULL for the errmsg parameter.
That tells PQconninfoParse to throw away the errmsg string anyway.
With that, the minimal case isn't much uglier than your original:
just ne
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Uh, you're confusing the backend environment with libpq's much more
>> spartan lifestyle. errmsg will be malloc'd and it will *not* go away
>> unless the caller free()s it.
> Yup, just figured that out. Otherwise OK with it?
Yeah. We c
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
If the return value is NULL, use errmsg if you'd like. I'd guess in most
instances you don't even need to bother freeing errmsg as it is in a
limited life memory context.
Uh, you're confusing the backend environment with libpq's much more
Joe Conway <[EMAIL PROTECTED]> writes:
> If the return value is NULL, use errmsg if you'd like. I'd guess in most
> instances you don't even need to bother freeing errmsg as it is in a
> limited life memory context.
Uh, you're confusing the backend environment with libpq's much more
spartan life
Tom Lane wrote:
Hmm ... one problem with this is that the caller can't tell
failure-because-out-of-memory from failure-because-string-is-bogus.
Is it worth having the
PQconninfoParse function pass back the error message to avoid this
corner case?
I thought briefly about it, and wasn't sure
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So that seems to tilt the decision towards exposing the conninfo_parse
>> function. Joe, do you want to have a go at it, or shall I?
> Here's a first shot.
Hmm ... one problem with this is that the caller can't tell
failure-because-out-
Tom Lane wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
On 9/21/08, Joe Conway <[EMAIL PROTECTED]> wrote:
Why? pg_service does not appear to support wildcards, so what is the attack
vector?
"service=foo host=custom"
The proposal to require a password = foo entry in the conn string seems
Joe Conway <[EMAIL PROTECTED]> writes:
> If we push the responsibility back to dblink, we might as well export
> conninfo_parse() or some wrapper thereof and let dblink simply check for
> a non-null password from the very beginning.
That's not totally unreasonable, since we already export the
PQ
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 9/21/08, Joe Conway <[EMAIL PROTECTED]> wrote:
>> Why? pg_service does not appear to support wildcards, so what is the attack
>> vector?
> "service=foo host=custom"
The proposal to require a password = foo entry in the conn string seems
to resolve al
Tom Lane wrote:
BTW, a possible hole in this scheme would be if a user could supply a
conninfo string that was intentionally malformed in a way that would
cause a tacked-on pgpassfile option to be ignored by libpq. We might
need to add some validity checks to dblink, or tighten libpq's own
check
Tom Lane wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
On 9/21/08, Joe Conway <[EMAIL PROTECTED]> wrote:
Why? pg_service does not appear to support wildcards, so what is the attack
vector?
"service=foo host=custom"
The proposal to require a password = foo entry in the conn string seems
On 9/21/08, Joe Conway <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> > You need to ignore pg_service also. (And PGPASSWORD)
>
> Why? pg_service does not appear to support wildcards, so what is the attack
> vector?
"service=foo host=custom"
> And on PGPASSWORD, the fine manual says the foll
Marko Kreen wrote:
On 9/21/08, Tom Lane <[EMAIL PROTECTED]> wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Good point -- I'll look into that and post something tomorrow. How does
> "requirepassword" sound for the option? It is consistent with
> "requiressl" but a bit long and hard to read. Ma
On 9/21/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Good point -- I'll look into that and post something tomorrow. How does
> > "requirepassword" sound for the option? It is consistent with
> > "requiressl" but a bit long and hard to read. Maybe "require_p
Joe Conway <[EMAIL PROTECTED]> writes:
> Good point -- I'll look into that and post something tomorrow. How does
> "requirepassword" sound for the option? It is consistent with
> "requiressl" but a bit long and hard to read. Maybe "require_password"?
Well, no, because it's not requiring a passwo
Tom Lane wrote:
I think there is an alternative solution, if we are only going to patch
this in 8.4 and up: provide a new libpq conninfo-string option saying
not to use .pgpass, and have dblink add that to the passed-in conninfo
string instead of trying to check after the fact. Then we aren't
ch
Joe Conway <[EMAIL PROTECTED]> writes:
> I took a look and can partially see Marko's point. The scenario exists
> within this context:
> 1. "superuser" installs dblink on db1, running on postgres server
> under the "superuser" account
> 2. "superuser" has .pgpass file
> 3. the "superuser" .pgp
I'm clearly out of practice -- this time with the attachment
Marko Kreen wrote:
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_service.conf contents of the OS user database is running
under to the non-privi
Marko Kreen wrote:
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_service.conf contents of the OS user database is running
under to the non-privileged database user. (Esp. passwords)
I took a look and can partially see Marko's point. The scenario exists
within thi
On 9/12/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Marko Kreen escribió:
>
> > Currently dblink allows regular users to initiate libpq connection
> > to user-provided connection string. This breaks the default
> > policy that normal users should not be allowed to freely interact
> > with o
On Fri, Sep 12, 2008 at 01:14:36PM -0400, Alvaro Herrera wrote:
> Marko Kreen escribió:
> > Currently dblink allows regular users to initiate libpq connection
> > to user-provided connection string. This breaks the default
> > policy that normal users should not be allowed to freely interact
> > w
Marko Kreen escribió:
> Currently dblink allows regular users to initiate libpq connection
> to user-provided connection string. This breaks the default
> policy that normal users should not be allowed to freely interact
> with outside environment.
Since people is now working on implementing the
Currently dblink allows regular users to initiate libpq connection
to user-provided connection string. This breaks the default
policy that normal users should not be allowed to freely interact
with outside environment.
In addition to breaking standard security policy, dblink exposes
.pgpass/pg_se
36 matches
Mail list logo
