On Wed, Jan 5, 2011 at 04:24, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 3, 2011 at 17:23, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert
On Wed, Jan 5, 2011 at 8:24 AM, Magnus Hagander mag...@hagander.net 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
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 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 superusers have
On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 3, 2011 at 17:23, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On the other hand, the REPLICATION
On Fri, Dec 31, 2010 at 15:38, Magnus Hagander mag...@hagander.net wrote:
On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut pete...@gmx.net 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
On Mon, Jan 3, 2011 at 6:00 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Dec 31, 2010 at 15:38, Magnus Hagander mag...@hagander.net wrote:
On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
I've applied
Robert Haas robertmh...@gmail.com 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
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Jan 3, 2011 at 17:23, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On the other hand, the REPLICATION privilege is denying you the right to
perform an operation *even though you
On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut pete...@gmx.net 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
On Wed, Dec 29, 2010 at 20:12, Alvaro Herrera
alvhe...@commandprompt.com 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 singh.gurj...@gmail.com wrote:
Any specific reason NOREPLICATION_P and REPLICATION_P use the
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
alvhe...@commandprompt.com wrote:
Some lexer keywords have a _P prefix because otherwise they'd collide
with some symbol in Windows header files or something like that.
On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
On Thu, Dec 30, 2010 at 9:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Magnus Hagander mag...@hagander.net 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
On Tue, Dec 28, 2010 at 13:05, Magnus Hagander mag...@hagander.net wrote:
On Mon, Dec 27, 2010 at 22:53, Magnus Hagander mag...@hagander.net wrote:
On Mon, Dec 27, 2010 at 22:42, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Updated patch, still pending docs,
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander mag...@hagander.netwrote:
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
On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander mag...@hagander.net
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
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 singh.gurj...@gmail.com 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
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 that
On Mon, Dec 27, 2010 at 09:32, Simon Riggs si...@2ndquadrant.com 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
On Mon, Dec 27, 2010 at 9:36 AM, Magnus Hagander mag...@hagander.net 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
On Fri, Dec 24, 2010 at 05:46, Stephen Frost sfr...@snowman.net 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
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 Mon, Dec 27, 2010 at 11:34, Simon Riggs si...@2ndquadrant.com 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?
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander mag...@hagander.net wrote:
On Fri, Dec 24, 2010 at 05:46, Stephen Frost sfr...@snowman.net 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
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
On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
On Mon, Dec 27, 2010 at 11:34, Simon Riggs si...@2ndquadrant.com 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
On Mon, Dec 27, 2010 at 14:25, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-12-27 at 12:00 +0100, Magnus Hagander wrote:
On Mon, Dec 27, 2010 at 11:34, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-12-27 at 10:36 +0100, Magnus Hagander wrote:
Is backup part of this new
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 discissions seem to have most
On Mon, Dec 27, 2010 at 14:51, Simon Riggs si...@2ndquadrant.com 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 get it
Magnus Hagander mag...@hagander.net writes:
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander mag...@hagander.net 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
On Mon, Dec 27, 2010 at 16:33, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander mag...@hagander.net wrote:
We could quite easily make a replication role *never* be able to
connect to a non-walsender backend. That
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
On Mon, Dec 27, 2010 at 16:45, Simon Riggs si...@2ndquadrant.com 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
On Mon, Dec 27, 2010 at 16:40, Magnus Hagander mag...@hagander.net wrote:
On Mon, Dec 27, 2010 at 16:33, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Dec 27, 2010 at 10:53, Magnus Hagander mag...@hagander.net wrote:
We could quite easily make a
Magnus Hagander mag...@hagander.net 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
On Mon, Dec 27, 2010 at 22:42, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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.
On Dec24, 2010, at 05:00 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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,
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
Magnus Hagander mag...@hagander.net 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
On Thu, Dec 23, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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,
Robert Haas robertmh...@gmail.com 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
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Thu, Dec 23, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Thu, Dec 23, 2010 at 16:57, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I haven't looked at the patch yet, but I think we should continue to
allow superuser-ness to be *sufficient*
Magnus Hagander mag...@hagander.net writes:
On Thu, Dec 23, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us 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
Magnus Hagander mag...@hagander.net writes:
On Thu, Dec 23, 2010 at 16:57, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't particularly mind breaking that. If we leave it as-is, we'll
be encouraging people to use superuser
On 12/23/2010 08:59 PM, Magnus Hagander wrote:
On Thu, Dec 23, 2010 at 16:57, Robert Haasrobertmh...@gmail.com wrote:
On Thu, Dec 23, 2010 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
I haven't looked at the patch yet, but I think we should
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
Josh Berkus j...@agliodbs.com 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.
On 12/23/10 2:21 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
* 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 more secure.
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 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
* 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 'for'
* 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
On Thu, Dec 23, 2010 at 23:44, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
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
On Thu, Dec 23, 2010 at 5:59 PM, Josh Berkus j...@agliodbs.com 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
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
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 surprise
Florian Pflug f...@phlo.org 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
On Dec24, 2010, at 04:16 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
Florian Pflug f...@phlo.org 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
On Thu, Dec 23, 2010 at 11:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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
* 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
70 matches
Mail list logo
