Re: [HACKERS] CATUPDATE confusion?

2015-03-16 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2015-03-16 Thread Robert Haas
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-16 Thread Adam Brightwell
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-13 Thread Robert Haas
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,

Re: [HACKERS] CATUPDATE confusion?

2015-03-13 Thread Stephen Frost
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-13 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2015-03-10 Thread Robert Haas
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-07 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2015-03-07 Thread Peter Eisentraut
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-07 Thread Adam Brightwell
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-06 Thread Adam Brightwell
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-06 Thread Peter Eisentraut
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:

Re: [HACKERS] CATUPDATE confusion?

2015-03-06 Thread Tom Lane
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-05 Thread Stephen Frost
* 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).

Re: [HACKERS] CATUPDATE confusion?

2015-03-04 Thread Tom Lane
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

Re: [HACKERS] CATUPDATE confusion?

2015-03-04 Thread Peter Eisentraut
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:

Re: [HACKERS] CATUPDATE confusion?

2015-03-03 Thread Peter Eisentraut
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

Re: [HACKERS] CATUPDATE confusion?

2015-02-28 Thread Stephen Frost
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

Re: [HACKERS] CATUPDATE confusion?

2015-02-28 Thread Peter Eisentraut
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

Re: [HACKERS] CATUPDATE confusion?

2015-02-25 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2015-02-25 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2015-02-25 Thread Peter Eisentraut
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

Re: [HACKERS] CATUPDATE confusion?

2015-02-24 Thread Michael Paquier
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

Re: [HACKERS] CATUPDATE confusion?

2015-02-19 Thread Peter Eisentraut
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'

Re: [HACKERS] CATUPDATE confusion?

2015-02-19 Thread Adam Brightwell
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

Re: [HACKERS] CATUPDATE confusion?

2015-01-19 Thread Adam Brightwell
* 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 -

Re: [HACKERS] CATUPDATE confusion?

2014-12-29 Thread 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

Re: [HACKERS] CATUPDATE confusion?

2014-12-29 Thread Stephen Frost
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

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Noah Misch
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

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Tom Lane
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

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Stephen Frost
* 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

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Tom Lane
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

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Noah Misch
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