On tis, 2011-01-04 at 22:24 -0500, Robert Haas wrote:
> > Just to be clear: are we saying that "CREATE ROLE foo SUPERUSER"
> > should grant both superuser and replication, as well as the default
> > "postgres" user also having replication as well?
>
> I think that's what we're saying.
So now supe
On mån, 2011-01-03 at 11:20 -0500, Tom Lane wrote:
> You might want to reflect on rolcatupdate a bit before asserting that
> there are no cases where privileges are ever denied to superusers.
Arguably, the reason that that is hardly documented and slightly
deprecated is that the underlying design
On Wed, Jan 5, 2011 at 8:24 AM, Magnus Hagander wrote:
> Ok, done and applied.
Thanks.
--
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 subscription:
http://
On Wed, Jan 5, 2011 at 04:24, Robert Haas wrote:
> On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander wrote:
>> On Mon, Jan 3, 2011 at 17:23, Robert Haas wrote:
>>> On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
Robert Haas writes:
> On the other hand, the REPLICATION privilege is deny
On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander wrote:
> On Mon, Jan 3, 2011 at 17:23, Robert Haas wrote:
>> On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
>>> Robert Haas writes:
On the other hand, the REPLICATION privilege is denying you the right to
perform an operation *even tho
On Mon, Jan 3, 2011 at 17:23, Robert Haas wrote:
> On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On the other hand, the REPLICATION privilege is denying you the right to
>>> perform an operation *even though you already are authenticated as a
>>> superuser*. I don'
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On the other hand, the REPLICATION privilege is denying you the right to
>> perform an operation *even though you already are authenticated as a
>> superuser*. I don't think there's anywhere else in the system where
>> we
Robert Haas writes:
> On the other hand, the REPLICATION privilege is denying you the right to
> perform an operation *even though you already are authenticated as a
> superuser*. I don't think there's anywhere else in the system where
> we allow a privilege to non-super-users but deny that same
On Mon, Jan 3, 2011 at 6:00 AM, Magnus Hagander wrote:
> On Fri, Dec 31, 2010 at 15:38, Magnus Hagander wrote:
>> On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut wrote:
>>> On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
I've applied this version (with some minor typo-fixes).
>>>
On Fri, Dec 31, 2010 at 15:38, Magnus Hagander wrote:
> On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut wrote:
>> On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
>>> I've applied this version (with some minor typo-fixes).
>>
>> This page is now somewhat invalidated:
>>
>> http://develop
On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut wrote:
> On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
>> I've applied this version (with some minor typo-fixes).
>
> This page is now somewhat invalidated:
>
> http://developer.postgresql.org/pgdocs/postgres/role-attributes.html
Hmm. So
Magnus Hagander writes:
> But yes, I see in commit 12c942383296bd626131241c012c2ab81b081738 the
> comment "convert some keywords.c symbols to KEYWORD_P to prevent
> conflict".
> Based on that, I should probably change it back, right? I just tried a
> patch for it and it compiles and checks just f
On Thu, Dec 30, 2010 at 9:54 AM, Peter Eisentraut wrote:
> On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
>> Josh Berkus writes:
>> > On 12/23/10 2:21 PM, Tom Lane wrote:
>> >> Well, that's one laudable goal here, but "secure by default" is another
>> >> one that ought to be taken into consid
On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
> I've applied this version (with some minor typo-fixes).
This page is now somewhat invalidated:
http://developer.postgresql.org/pgdocs/postgres/role-attributes.html
First, it doesn't mention the replication privilege, and second it
conti
On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
> Josh Berkus writes:
> > On 12/23/10 2:21 PM, Tom Lane wrote:
> >> Well, that's one laudable goal here, but "secure by default" is another
> >> one that ought to be taken into consideration.
>
> > I don't see how *not* granting the superuser rep
Excerpts from Magnus Hagander's message of jue dic 30 08:57:09 -0300 2010:
> On Wed, Dec 29, 2010 at 20:12, Alvaro Herrera
> wrote:
> > Some lexer keywords have a _P prefix because otherwise they'd collide
> > with some symbol in Windows header files or something like that. It's
> > old stuff, b
On Wed, Dec 29, 2010 at 20:12, Alvaro Herrera
wrote:
> Excerpts from Magnus Hagander's message of mié dic 29 11:40:34 -0300 2010:
>> On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh wrote:
>
>> > Any specific reason NOREPLICATION_P and REPLICATION_P use the _P suffix?
>>
>> Um, I just copied it off a
Excerpts from Magnus Hagander's message of mié dic 29 11:40:34 -0300 2010:
> On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh wrote:
> > Any specific reason NOREPLICATION_P and REPLICATION_P use the _P suffix?
>
> Um, I just copied it off a similar entry elsewhere. I saw no comment
> about what _P a
On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh wrote:
> On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander
> wrote:
>>
>> > Ok, here's an updated patch that does both these and includes
>> > documentation and regression test changes. With that, I think we're
>> > good to go.
>>
>> I've applied this v
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander wrote:
> > Ok, here's an updated patch that does both these and includes
> > documentation and regression test changes. With that, I think we're
> > good to go.
>
> I've applied this version (with some minor typo-fixes).
>
>
Do you think we could ha
On Tue, Dec 28, 2010 at 13:05, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 22:53, Magnus Hagander wrote:
>> On Mon, Dec 27, 2010 at 22:42, Tom Lane wrote:
>>> Magnus Hagander writes:
Updated patch, still pending docs, but otherwise updated: allow
start/stop backup, make sure only
On Mon, Dec 27, 2010 at 22:42, Tom Lane wrote:
> Magnus Hagander writes:
>> Updated patch, still pending docs, but otherwise updated: allow
>> start/stop backup, make sure only superuser can turn on/off the flag,
>> include in system views, show properly in psql.
>
> I'd suggest avoiding creating
Magnus Hagander writes:
> Updated patch, still pending docs, but otherwise updated: allow
> start/stop backup, make sure only superuser can turn on/off the flag,
> include in system views, show properly in psql.
I'd suggest avoiding creating the static cache variable
AuthenticatedUserIsReplicatio
On Mon, Dec 27, 2010 at 16:40, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 16:33, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
We could quite easily make a replication role *never* be able to
connect to a non-walsender backe
On Mon, Dec 27, 2010 at 16:45, Simon Riggs wrote:
> On Mon, 2010-12-27 at 14:54 +0100, Magnus Hagander wrote:
>
>> You will certainly be able to log into the standby with a superuser
>> account, nobody is preventing that. This is about protecting the
>> *master*. For example, from modifications ma
On Mon, 2010-12-27 at 14:54 +0100, Magnus Hagander wrote:
> You will certainly be able to log into the standby with a superuser
> account, nobody is preventing that. This is about protecting the
> *master*. For example, from modifications made by a user who hacked
> the standby.
The users for ma
On Mon, Dec 27, 2010 at 16:33, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
>>> We could quite easily make a replication role *never* be able to
>>> connect to a non-walsender backend. That would mean that if you set
>>> your role to WITH REP
Magnus Hagander writes:
> On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
>> We could quite easily make a replication role *never* be able to
>> connect to a non-walsender backend. That would mean that if you set
>> your role to WITH REPLICATION, it can *only* be used for replication
>> and
On Mon, Dec 27, 2010 at 14:51, Simon Riggs wrote:
> On Mon, 2010-12-27 at 14:41 +0100, Magnus Hagander wrote:
>> >> >
>> >> > Where does pg_start_backup()/stop fit?
>> >>
>> >> Good question :)
>> >>
>> >> Given that the integrated-base-backup would call it for you, that one
>> >> would definitely
On Mon, 2010-12-27 at 14:41 +0100, Magnus Hagander wrote:
> >> >
> >> > Where does pg_start_backup()/stop fit?
> >>
> >> Good question :)
> >>
> >> Given that the integrated-base-backup would call it for you, that one
> >> would definitely get it automatically.
> >>
> >> Given that the latest disci
On Mon, Dec 27, 2010 at 14:25, Simon Riggs wrote:
> On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
>> On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
>> > On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
>> >> > Is backup part of this new privilege, or not?
>> >>
>> >> The "
On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
> On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
> > On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
> >> > Is backup part of this new privilege, or not?
> >>
> >> The "integrated base backup", once we have that, that's based o
On Dec27, 2010, at 12:15 , Magnus Hagander wrote:
> Actually, having implemented that and tested it, I realize that's a
> pretty bad idea. For one thing, it broke my own pg_streamrecv program,
> since it requires the ability to connect to the master and select a
> pg_current_xlog_location().
I'm s
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander wrote:
> On Fri, Dec 24, 2010 at 05:46, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> I think I agree with Florian about the confusing-ness of the proposed
>>> semantics. Aren't you saying you want NOLOGIN mean "not allowe
On Mon, Dec 27, 2010 at 11:34, Simon Riggs wrote:
> On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
>> > Is backup part of this new privilege, or not?
>>
>> The "integrated base backup", once we have that, that's based on the
>> walsender protocol? yes.
>> pg_dump style backups? No.
>
>
On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
> > Is backup part of this new privilege, or not?
>
> The "integrated base backup", once we have that, that's based on the
> walsender protocol? yes.
> pg_dump style backups? No.
Where does pg_start_backup()/stop fit?
--
Simon Riggs
On Fri, Dec 24, 2010 at 05:46, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I think I agree with Florian about the confusing-ness of the proposed
>> semantics. Aren't you saying you want NOLOGIN mean "not allowed to
>> log in for the purposes of issuing SQL commands, but
On Mon, Dec 27, 2010 at 9:36 AM, Magnus Hagander wrote:
> Seeing logged SQL isn't - but being able to filter the logfiles on
> that requires a *lot* more than just defining a security privilege. If
> we mean "arbitrary log file reading", the easiest way to fix that
> would be to stop checking for
On Mon, Dec 27, 2010 at 09:32, Simon Riggs wrote:
> On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
>
>> Here's a patch that changes walsender to require a special privilege
>> for replication instead of relying on superuser permissions. We
>> discussed this back before 9.0 was finalized
On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
> Here's a patch that changes walsender to require a special privilege
> for replication instead of relying on superuser permissions. We
> discussed this back before 9.0 was finalized, but IIRC we ran out of
> time. The motivation being tha
On Dec24, 2010, at 05:00 , Tom Lane wrote:
> Florian Pflug writes:
>> The problem here is that you suggest NOLOGIN should mean "Not allowed
>> to issue SQL commands", which really isn't what the name "NOLOGIN"
>> conveys.
>
> No, it means "not allowed to connect".
Exactly. Which proves my point,
* Robert Haas (robertmh...@gmail.com) wrote:
> I think I agree with Florian about the confusing-ness of the proposed
> semantics. Aren't you saying you want NOLOGIN mean "not allowed to
> log in for the purposes of issuing SQL commands, but allowed to log in
> for replication"? Uggh.
I like the
On Thu, Dec 23, 2010 at 11:00 PM, Tom Lane wrote:
> Florian Pflug writes:
>> The problem here is that you suggest NOLOGIN should mean "Not allowed
>> to issue SQL commands", which really isn't what the name "NOLOGIN"
>> conveys.
>
> No, it means "not allowed to connect". It's possible now to iss
Florian Pflug writes:
> The problem here is that you suggest NOLOGIN should mean "Not allowed
> to issue SQL commands", which really isn't what the name "NOLOGIN"
> conveys.
No, it means "not allowed to connect". It's possible now to issue
commands as a NOLOGIN user, you just have to use SET ROL
On Dec24, 2010, at 04:16 , Tom Lane wrote:
> Florian Pflug writes:
>> On Dec23, 2010, at 16:54 , Tom Lane wrote:
>>> BTW, is it possible to set things up so that a REPLICATION account
>>> can be NOLOGIN, thereby making it really hard to abuse for other
>>> purposes? Or does the login privilege ch
Florian Pflug writes:
> On Dec23, 2010, at 16:54 , Tom Lane wrote:
>> BTW, is it possible to set things up so that a REPLICATION account
>> can be NOLOGIN, thereby making it really hard to abuse for other
>> purposes? Or does the login privilege check come too soon?
> Please don't. This violates
On Dec23, 2010, at 16:54 , Tom Lane wrote:
> BTW, is it possible to set things up so that a REPLICATION account
> can be NOLOGIN, thereby making it really hard to abuse for other
> purposes? Or does the login privilege check come too soon?
Please don't. This violates the principle of least surpri
> If the user exists but is disabled by default, I'm not sure that
> really provides any advantage over not having it at all. And it
> certainly can't be enabled by default.
I was presuming that NOLOGIN wouldn't prevent a replication connections
via the replication user. So the user would be "e
On Thu, Dec 23, 2010 at 5:59 PM, Josh Berkus wrote:
>
>> I'm not entirely sure about this one.. I'm not against it but I'm also
>> not really 'for' it. :)
>
> 2 reasons: (a) if users need to CREATE USER, that *does* add an extra
> step and they're more likely to just choose to grant to postgres
>
> I'm not entirely sure about this one.. I'm not against it but I'm also
> not really 'for' it. :)
2 reasons: (a) if users need to CREATE USER, that *does* add an extra
step and they're more likely to just choose to grant to postgres
instead, (b) having a standard installed user (just like the u
On Thu, Dec 23, 2010 at 23:44, Tom Lane wrote:
> Josh Berkus writes:
>> On 12/23/10 2:33 PM, Stephen Frost wrote:
>>> A better alternative, imv, would be to just have a & d, and mention in
>>> the release notes that users *should* create a dedicated replication
>>> role which is *not* a superuser
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> However, it'd be a real good idea for that role to be NOLOGIN if it's
> there by default.
Definitely. I'd also suggest we WARN if someone creates a situation
where a role has both replication and login, and maybe prevent it
altogether, it's just a bad idea
* Josh Berkus (j...@agliodbs.com) wrote:
> 1) have a replication permission
Right, that's what this patch is about.
> 2) *by default* create a replication user with the replication
> permission when we initdb.
I'm not entirely sure about this one.. I'm not against it but I'm also
not really 'fo
Josh Berkus writes:
> On 12/23/10 2:33 PM, Stephen Frost wrote:
>> A better alternative, imv, would be to just have a & d, and mention in
>> the release notes that users *should* create a dedicated replication
>> role which is *not* a superuser but *does* have the replication grant,
>> but if they
On 12/23/10 2:33 PM, Stephen Frost wrote:
> A better alternative, imv, would be to just have a & d, and mention in
> the release notes that users *should* create a dedicated replication
> role which is *not* a superuser but *does* have the replication grant,
> but if they don't want to change their
* Josh Berkus (j...@agliodbs.com) wrote:
> On 12/23/10 2:21 PM, Tom Lane wrote:
> > Well, that's one laudable goal here, but "secure by default" is another
> > one that ought to be taken into consideration.
>
> I don't see how *not* granting the superuser replication permissions
> makes things mor
Josh Berkus writes:
> On 12/23/10 2:21 PM, Tom Lane wrote:
>> Well, that's one laudable goal here, but "secure by default" is another
>> one that ought to be taken into consideration.
> I don't see how *not* granting the superuser replication permissions
> makes things more secure. The superuser
On 12/23/10 2:21 PM, Tom Lane wrote:
> Josh Berkus writes:
>> If we still make it possible for "postgres" to replicate, then we don't
>> add any complexity to the simplest setup.
>
> Well, that's one laudable goal here, but "secure by default" is another
> one that ought to be taken into consider
Josh Berkus writes:
> If we still make it possible for "postgres" to replicate, then we don't
> add any complexity to the simplest setup.
Well, that's one laudable goal here, but "secure by default" is another
one that ought to be taken into consideration.
regards, tom la
On 12/23/10 7:49 AM, Robert Haas wrote:
> I haven't looked at the patch yet, but I think we should continue to
> allow superuser-ness to be *sufficient* for replication - i.e.
> superusers will automatically have the replication privilege just as
> they do any other - and merely allow this as an op
On 12/23/2010 08:59 PM, Magnus Hagander wrote:
On Thu, Dec 23, 2010 at 16:57, Robert Haas wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
Robert Haas writes:
I haven't looked at the patch yet, but I think we should continue to
allow superuser-ness to be *sufficient* for replication
Magnus Hagander writes:
> On Thu, Dec 23, 2010 at 16:57, Robert Haas wrote:
>> On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
>>> I don't particularly mind breaking that. If we leave it as-is, we'll
>>> be encouraging people to use superuser accounts for things that don't
>>> need that, whic
Magnus Hagander writes:
> On Thu, Dec 23, 2010 at 16:15, Tom Lane wrote:
>> I think only superusers should be allowed to change the flag.
> That was certainly not intentional - and doesn't work that way for me
> at least, unless I broke it right before I submitted it.
> oh hang on.. Yeah, it's
On Thu, Dec 23, 2010 at 16:57, Robert Haas wrote:
> On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I haven't looked at the patch yet, but I think we should continue to
>>> allow superuser-ness to be *sufficient* for replication - i.e.
>>> superusers will automatical
On Thu, Dec 23, 2010 at 16:15, Tom Lane wrote:
> Magnus Hagander writes:
>> Here's a patch that changes walsender to require a special privilege
>> for replication instead of relying on superuser permissions. We
>> discussed this back before 9.0 was finalized, but IIRC we ran out of
>> time. The
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> I haven't looked at the patch yet, but I think we should continue to
>> allow superuser-ness to be *sufficient* for replication - i.e.
>> superusers will automatically have the replication privilege just as
>> they do any
Robert Haas writes:
> I haven't looked at the patch yet, but I think we should continue to
> allow superuser-ness to be *sufficient* for replication - i.e.
> superusers will automatically have the replication privilege just as
> they do any other - and merely allow this as an option for when you
>
On Thu, Dec 23, 2010 at 10:15 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> Here's a patch that changes walsender to require a special privilege
>> for replication instead of relying on superuser permissions. We
>> discussed this back before 9.0 was finalized, but IIRC we ran out of
>> time. T
Magnus Hagander writes:
> Here's a patch that changes walsender to require a special privilege
> for replication instead of relying on superuser permissions. We
> discussed this back before 9.0 was finalized, but IIRC we ran out of
> time. The motivation being that you really want to use superuser
Here's a patch that changes walsender to require a special privilege
for replication instead of relying on superuser permissions. We
discussed this back before 9.0 was finalized, but IIRC we ran out of
time. The motivation being that you really want to use superuser as
little as possible - and sinc
70 matches
Mail list logo
