* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Mar 13, 2015 at 9:52 AM, Stephen Frost sfr...@snowman.net wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
I should have been more specific. I don't believe they've moved to
using pg_roles completely (which was created specifically to
On Fri, Mar 13, 2015 at 9:52 AM, Stephen Frost sfr...@snowman.net wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
I should have been more specific. I don't believe they've moved to
using pg_roles completely (which was created specifically to address the
issue that regular users can't
All,
Sure, if we never deprecate anything then tool authors would never need
to change their existing code. I don't think that's actually a viable
solution though; the reason we're discussing the removal of these
particular views is that they aren't really being maintained and, when
they
On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost sfr...@snowman.net wrote:
As near as I can tell, pgAdmin3 does still use pg_user (though I don't
think it uses pg_group or pg_shadow except when connected to an ancient
server) in some cases. Where it is used, based on my quick review at
least,
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost sfr...@snowman.net wrote:
Basically, in my view at least, these programs are likely to continue to
use these backwards compatibility views until we either formally
deprecate them or (more
* Stephen Frost (sfr...@snowman.net) wrote:
I should have been more specific. I don't believe they've moved to
using pg_roles completely (which was created specifically to address the
issue that regular users can't select from pg_authid).
Err, forgot to finish that thought, sorry. Let's
On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
pg_shadow, pg_user and pg_group were added when role support was added,
specifically for backwards compatibility. I don't believe there was
ever discussion about keeping them because filtering
* Peter Eisentraut (pete...@gmx.net) wrote:
On 3/7/15 12:31 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
committed this version
On 3/7/15 12:31 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
committed this version
Hmm .. I'm not sure that summarily removing
All,
pg_shadow, pg_user and pg_group were added when role support was added,
specifically for backwards compatibility. I don't believe there was
ever discussion about keeping them because filtering pg_roles based on
rolcanlogin was too onerous. That said, we already decided recently
that
All,
Thanks for all the feedback and review.
I think I vote for (1). I do not like (2) because of the argument I made
upthread that write access on system catalogs is far more dangerous than
a naive DBA might think. (0) has some attraction but really CATUPDATE
is one more concept than
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
committed this version
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Eisentraut pete...@gmx.net writes:
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
committed this version
Hmm .. I'm not sure that summarily removing usecatupd from those three
system views was
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Eisentraut pete...@gmx.net writes:
Any other opinions?
The options are:
0) Leave as is.
1) Remove catupdate and replace with superuser checks.
2) Remove catupdate and rely on regular table permissions on catalogs.
I think I vote for (1).
Peter Eisentraut pete...@gmx.net writes:
Any other opinions?
The options are:
0) Leave as is.
1) Remove catupdate and replace with superuser checks.
2) Remove catupdate and rely on regular table permissions on catalogs.
I think I vote for (1). I do not like (2) because of the argument I
Any other opinions?
The options are:
0) Leave as is.
1) Remove catupdate and replace with superuser checks.
2) Remove catupdate and rely on regular table permissions on catalogs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2/28/15 6:32 PM, Stephen Frost wrote:
This isn't really /etc/shadow though, this is more like direct access to
the filesystem through the device node- and you'll note that Linux
certainly has got an independent set of permissions for that called the
capabilities system. That's because
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/25/15 10:05 PM, Stephen Frost wrote:
Agreed, but I'd also like to get rid of any reason, beyond emergency
cases, for people to modify the catalog directly. There's a few places
which we aren't yet doing that, but I'd rather fix those
On 2/25/15 10:05 PM, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/25/15 3:39 PM, Stephen Frost wrote:
I'd get rid of that whole check, not just replace rolcatupdate by rolsuper.
Err, wouldn't this make it possible to grant normal users the ability to
modify system
* Peter Eisentraut (pete...@gmx.net) wrote:
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
One of the interesting behaviors (or perhaps not) is how
'pg_class_aclmask' handles an invalid role id
* Peter Eisentraut (pete...@gmx.net) wrote:
On 2/25/15 3:39 PM, Stephen Frost wrote:
I'd get rid of that whole check, not just replace rolcatupdate by rolsuper.
Err, wouldn't this make it possible to grant normal users the ability to
modify system catalogs? I realize that they wouldn't
On 2/25/15 3:39 PM, Stephen Frost wrote:
I'd get rid of that whole check, not just replace rolcatupdate by rolsuper.
Err, wouldn't this make it possible to grant normal users the ability to
modify system catalogs? I realize that they wouldn't have that
initially, but I'm not sure we want
On Fri, Feb 20, 2015 at 8:08 AM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
Thanks for the review and feedback.
One of the interesting behaviors (or perhaps not) is how
'pg_class_aclmask' handles an invalid role id when checking permissions
against 'rolsuper' instead
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
One of the interesting behaviors (or perhaps not) is how
'pg_class_aclmask' handles an invalid role id when checking permissions
against 'rolsuper'
Peter,
Thanks for the review and feedback.
One of the interesting behaviors (or perhaps not) is how
'pg_class_aclmask' handles an invalid role id when checking permissions
against 'rolsuper' instead of 'rolcatupdate'.
I'd get rid of that whole check, not just replace rolcatupdate by
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
Given this discussion, I have attached a patch that removes CATUPDATE for
review/discussion.
Thanks!
I've added this patch (up-thread) to the next CommitFest (2015-02).
-Adam
--
Adam Brightwell -
All,
On Sat, Dec 27, 2014 at 6:31 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Plan C (remove CATUPDATE altogether) also has some merit. But adding
a
Adam,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
Given this discussion, I have attached a patch that removes CATUPDATE for
review/discussion.
Thanks!
One of the interesting behaviors (or perhaps not) is how 'pg_class_aclmask'
handles an invalid role id when checking
On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote:
So, where I find this confusing is that the documentation supports this
functionality and the check keeps superuser separate from CATUPDATE...
however... comments and implementation in user.c state/do the opposite and
couple them
* Noah Misch (n...@leadboat.com) wrote:
On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote:
Perhaps this is not an issue but it seemed odd to me, especially after
giving Peter's comment more thought. So, I suppose the question is whether
or not a superuser check should be
Stephen Frost sfr...@snowman.net writes:
* Noah Misch (n...@leadboat.com) wrote:
On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote:
Perhaps this is not an issue but it seemed odd to me, especially after
giving Peter's comment more thought. So, I suppose the question is whether
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Plan C (remove CATUPDATE altogether) also has some merit. But adding a
superuser override there would be entirely pointless.
This is be my recommendation. I do not see the point of carrying the
option around just to confuse new users of pg_authid and
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Plan C (remove CATUPDATE altogether) also has some merit. But adding a
superuser override there would be entirely pointless.
This is be my recommendation. I do not see the point of carrying the
option around
On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Plan C (remove CATUPDATE altogether) also has some merit. But adding a
superuser override there would be entirely pointless.
This is be my
All,
While reviewing the supporting documentation and functions for role
attributes I noticed that there seems to be some confusion (at least for
me) with CATUPDATE.
This was prompted by the following comment from Peter about
'has_rolcatupdate' not having a superuser check.
35 matches
Mail list logo
