Hi,
I've just recently upgraded to postgrsql 9.1 and also hit bug #5763.
Having +group not match all superusers is essential to be able to assign
different authentication backends to different superusers with needing
to edit configuration files on the radius host system. E.g. to be able
to
On 08/14/2012 05:03 PM, Michael Braun wrote:
Hi,
I've just recently upgraded to postgrsql 9.1 and also hit bug #5763.
Having +group not match all superusers is essential to be able to assign
different authentication backends to different superusers with needing
to edit configuration files on
On 09/11/2011 09:40 PM, Andrew Dunstan wrote:
On 09/09/2011 11:34 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjianbr...@momjian.us
wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members
On Wed, Nov 2, 2011 at 3:27 PM, Andrew Dunstan and...@dunslane.net wrote:
Patch with a small docs addition also. Adding to Nov commitfest.
I have reviewed this and it looks good to me. Marking Ready for Committer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
* Andrew Dunstan (and...@dunslane.net) wrote:
It's NOT changing that. All this affects is how +groupname is
treated in pg_hba.conf, i.e. do we treat every superuser there as
being a member of every group.
Ah, sorry for the noise, that's fine (and I'm bit suprised it was a
one-liner, guess I
On 09/09/2011 11:34 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjianbr...@momjian.us wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all groups
* Andrew Dunstan (and...@dunslane.net) wrote:
Address problem where superusers are assumed to be members of all groups
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
This turns out to be a one-liner.
I really don't know that I agree with removing this,
On Sun, Sep 11, 2011 at 10:32 PM, Stephen Frost sfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
Address problem where superusers are assumed to be members of all
groups
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
This turns out
On 09/11/2011 10:32 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
Address problem where superusers are assumed to be members of all groups
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00337.php
This turns out to be a one-liner.
Robert Haas wrote:
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian br...@momjian.us wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all groups
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian br...@momjian.us wrote:
Is this a TODO?
I think so.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Andrew Dunstan wrote:
On 04/07/2011 11:01 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then
On Thu, Apr 7, 2011 at 6:49 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/07/2011 12:29 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frostsfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising
On 04/07/2011 03:48 AM, Alastair Turner wrote:
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that they apply to superuser?
I think that's just about
On 04/07/2011 07:33 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more reason.
I
Andrew Dunstan and...@dunslane.net writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then that's probably the way to go.
Otherwise it seems more trouble than
On 04/07/2011 11:01 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then that's probably the way to go.
I just hit this, which at least violated my sense of least astonishment,
if it's not an outright bug:
After creating a role foo, I added to following lines to my (9.0)
pg_hba.conf:
localall +foo reject
host all +foo 0.0.0.0/0 reject
The surprising (to me)
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising (to me) consequence was that every superuser was
locked out of the system. I had not granted them (or anyone) the
role, but nevertheless these lines took effect.
As I recall, the way we allow superusers to set role to other roles is
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost sfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising (to me) consequence was that every superuser was
locked out of the system. I had not granted them (or anyone) the
role, but nevertheless these lines took effect.
See bug #5763, and subsequent emails. Short version: Tom argued it
wasn't a bug; Peter and I felt that it was.
Add my vote: it's a bug.
Users who fall afoul of this will spend *hours* trying to debug this
before they stumble on the correct answer. pg_hba.conf is confusing
enough as it is.
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost sfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising (to me) consequence was that every superuser was
locked out of the system. I had not granted them (or anyone) the
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more reason.
Actually, I find that behavior
On 04/07/2011 12:29 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frostsfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
The surprising (to me) consequence was that every superuser was
locked out of the system. I
26 matches
Mail list logo
