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
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 13, 2015 at 9:52 AM, Stephen Frost 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 th
On Fri, Mar 13, 2015 at 9:52 AM, Stephen Frost 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 select from pg_au
* 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
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost 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 likely) until
On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost 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, it looks like i
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell
> 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 bec
On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell
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 pg_roles based on
>> rolcanlogin was too
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
> t
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 3/7/15 12:31 AM, Tom Lane wrote:
> > Peter Eisentraut 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 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
Peter Eisentraut 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 well thought
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:
http://www.postgresql.
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut 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 d
Peter Eisentraut 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 made
upthread
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:
http
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 m
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
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
>>> m
* 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
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 wa
* 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
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 'rolsup
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
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' i
>
> * 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 - adam.brightw..
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 check
All,
On Sat, Dec 27, 2014 at 6:31 PM, Noah Misch wrote:
> On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote:
> > Stephen Frost writes:
> > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > >> Plan C (remove CATUPDATE altogether) also has some merit. But adding
> a
> > >> superuser override t
On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote:
> Stephen Frost 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.
Stephen Frost 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 just to confus
* 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
Stephen Frost 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
>>> or not
* 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 b
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 t
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.
http://www.postgresql
36 matches
Mail list logo
