On Fri, Jan 13, 2023 at 2:17 AM Noah Misch wrote:
> Since the text is superfluous but not wrong, I won't insist.
OK, committed as I had it, then.
To me, the text isn't superfluous, because otherwise the connection to
what has been said in the previous sentence seems tenuous, which
impacts
On Thu, Jan 12, 2023 at 10:21:32AM -0500, Robert Haas wrote:
> On Thu, Jan 12, 2023 at 12:09 AM Noah Misch wrote:
> > > --- a/doc/src/sgml/ref/grant.sgml
> > > +++ b/doc/src/sgml/ref/grant.sgml
> > > @@ -298,6 +298,20 @@ GRANT > > class="parameter">role_name [, ...] TO > > This option
On Thu, Jan 12, 2023 at 12:09 AM Noah Misch wrote:
> I think this is good to go modulo one or two things:
>
> > Subject: [PATCH v2] More documentation update for GRANT ... WITH SET OPTION.
> >
> > Update the reference pages for various ALTER commands that
> > mentioned that you must be a member
On Wed, Jan 11, 2023 at 03:13:29PM -0500, Robert Haas wrote:
> On Wed, Jan 11, 2023 at 10:16 AM Noah Misch wrote:
> > I still think docs for the SET option itself should give a sense of the
> > diversity of things it's intended to control. It could be simple. A bunch
> > of
> > the sites
On Wed, Jan 11, 2023 at 10:16 AM Noah Misch wrote:
> A "git grep 'direct or indirect mem'" found a few more:
>
> doc/src/sgml/ref/alter_collation.sgml:42: To alter the owner, you must also
> be a direct or indirect member of the new
> doc/src/sgml/ref/create_database.sgml:92:role, you
On Tue, Jan 10, 2023 at 11:06:52AM -0500, Robert Haas wrote:
> On Sat, Jan 7, 2023 at 12:00 AM Noah Misch wrote:
> > The docs are silent on the SET / OWNER TO connection. Hence,
>
> Reviewing the documentation again today, I realized that the
> documentation describes the rules for changing the
On Tue, 2023-01-10 at 11:45 -0500, Robert Haas wrote:
> So the risks, which in theory are all very similar, are in practice
> far greater in the PostgreSQL context, basically because our default
> setup is about 40 years behind the times in terms of implementing
> best
> practices.
I agree that
On Tue, Jan 10, 2023 at 2:28 AM Jeff Davis wrote:
> The risks of SECURITY INVOKER are more serious. It inherently means
> that one user is writing code, and another is executing it. And in the
> SQL world of triggers, views, expression indexes and logical
> replication, the invoker often doesn't
On Sat, Jan 7, 2023 at 12:00 AM Noah Misch wrote:
> The docs are silent on the SET / OWNER TO connection. Hence,
Reviewing the documentation again today, I realized that the
documentation describes the rules for changing the ownership of an
object in a whole bunch of places which this patch
On Fri, 2022-12-30 at 22:16 -0800, Noah Misch wrote:
> create user unpriv;
> grant pg_maintain to unpriv with set false;
> create schema maint authorization pg_maintain
> create table t (c int);
> create or replace function maint.f() returns int language sql as
> 'select 1';
> alter function
On Wed, Jan 04, 2023 at 03:56:34PM -0500, Robert Haas wrote:
> On Tue, Jan 3, 2023 at 5:03 PM Noah Misch wrote:
> > I'd start with locations where the patch already added documentation. In
> > the
> > absence of documentation otherwise, a reasonable person could think WITH SET
> > controls just
On Tue, Jan 3, 2023 at 5:03 PM Noah Misch wrote:
> I'd start with locations where the patch already added documentation. In the
> absence of documentation otherwise, a reasonable person could think WITH SET
> controls just SET ROLE. The documentation of WITH SET is a good place to list
> what
On Tue, Jan 03, 2023 at 02:43:10PM -0500, Robert Haas wrote:
> On Sat, Dec 31, 2022 at 1:16 AM Noah Misch wrote:
> > On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote:
> > > On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote:
> > > > But I think the bigger reason is that, in my
On Sat, Dec 31, 2022 at 1:16 AM Noah Misch wrote:
> On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote:
> > On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote:
> > > But I think the bigger reason is that, in my opinion, this proposal is
> > > more generally useful, because it takes no
On Thu, Nov 17, 2022 at 04:24:24PM -0800, Jeff Davis wrote:
> On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote:
> > But I think the bigger reason is that, in my opinion, this proposal is
> > more generally useful, because it takes no position on why you wish to
> > disallow SET ROLE. You can
On Mon, Nov 21, 2022 at 10:45:53AM -0500, Robert Haas wrote:
> Seems like a good idea but I'm not sure about this hunk:
>
> TailMatches("GRANT|REVOKE", "ALTER", "SYSTEM") ||
> - TailMatches("REVOKE", "GRANT", "OPTION", "FOR", "ALTER", "SYSTEM"))
> + TailMatches("REVOKE", "GRANT", "OPTION",
идея и её реализация насчёт Параллельного чтения - как вам? Мне
показалось, интересно и полезно. Но это, думаю, одноразовая акция.
Времени и сил на это довольно много ухлопал, хотя вроде дело нехитрое
:) Стоило?
15.11.2022 20:07, Robert Haas пишет:
Bump.
Discussion has trailed off here,
On Sat, Nov 19, 2022 at 1:00 AM Michael Paquier wrote:
> On Fri, Nov 18, 2022 at 04:19:15PM -0500, Robert Haas wrote:
> > Fixed that, and the other mistake Álvaro spotted, and also bumped
> > catversion because I forgot that earlier.
>
> I was looking at this code yesterday, to see today that
On Fri, Nov 18, 2022 at 04:19:15PM -0500, Robert Haas wrote:
> On Fri, Nov 18, 2022 at 1:50 PM Erik Rijkers wrote:
> > In grant.sgml,
> >
> >'actualy permisions'
> >
> > looks a bit unorthodox.
>
> Fixed that, and the other mistake Álvaro spotted, and also bumped
> catversion because I
On Fri, Nov 18, 2022 at 04:19:15PM -0500, Robert Haas wrote:
> Fixed that, and the other mistake Álvaro spotted, and also bumped
> catversion because I forgot that earlier.
I was looking at this code yesterday, to see today that psql's
completion should be completed with this new clause, similary
Op 18-11-2022 om 22:19 schreef Robert Haas:
On Fri, Nov 18, 2022 at 1:50 PM Erik Rijkers wrote:
In grant.sgml,
'actualy permisions'
looks a bit unorthodox.
Fixed that, and the other mistake Álvaro spotted, and also bumped
catversion because I forgot that earlier.
Sorry to be nagging
On Fri, Nov 18, 2022 at 1:50 PM Erik Rijkers wrote:
> In grant.sgml,
>
>'actualy permisions'
>
> looks a bit unorthodox.
Fixed that, and the other mistake Álvaro spotted, and also bumped
catversion because I forgot that earlier.
--
Robert Haas
EDB: http://www.enterprisedb.com
Op 18-11-2022 om 19:43 schreef Robert Haas:
On Fri, Nov 18, 2022 at 12:50 PM Robert Haas wrote:
Here's a rebased v3 to see what cfbot thinks.
cfbot is happy, so committed.
In grant.sgml,
'actualy permisions'
looks a bit unorthodox.
On Fri, Nov 18, 2022 at 12:50 PM Robert Haas wrote:
> Here's a rebased v3 to see what cfbot thinks.
cfbot is happy, so committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 2022-Nov-18, Robert Haas wrote:
> On Thu, Nov 17, 2022 at 7:24 PM Jeff Davis wrote:
> > But I'm fine if you'd like to move on with the SET ROLE privilege
> > instead, as long as we believe it grants a stable set of capabilities
> > (and conversely, that if the SET ROLE privilege is revoked,
On Thu, Nov 17, 2022 at 7:24 PM Jeff Davis wrote:
> But I'm fine if you'd like to move on with the SET ROLE privilege
> instead, as long as we believe it grants a stable set of capabilities
> (and conversely, that if the SET ROLE privilege is revoked, that it
> revokes a stable set of
On Thu, 2022-11-17 at 16:52 -0500, Robert Haas wrote:
> But I think the bigger
> reason is that, in my opinion, this proposal is more generally
> useful,
> because it takes no position on why you wish to disallow SET ROLE.
> You
> can just disallow it in some cases and allow it in others, and
On Tue, Nov 15, 2022 at 7:23 PM Jeff Davis wrote:
> On Tue, 2022-11-15 at 12:07 -0500, Robert Haas wrote:
> > If anyone else wants to comment, or if either of those people want to
> > comment further, please speak up soon.
>
> Did you have some thoughts on:
>
>
On Tue, 2022-11-15 at 12:07 -0500, Robert Haas wrote:
> If anyone else wants to comment, or if either of those people want to
> comment further, please speak up soon.
Did you have some thoughts on:
https://postgr.es/m/a41d606d03b629c2ef0ed274ae3b04a2c266.ca...@j-davis.com
Regards,
On Tue, Nov 15, 2022 at 12:07:06PM -0500, Robert Haas wrote:
> If anyone else wants to comment, or if either of those people want to
> comment further, please speak up soon. Otherwise, I am going to press
> forward with committing this.
I don't think I have any further thoughts about the
Bump.
Discussion has trailed off here, but I still don't see that we have a
better way forward here than what I proposed on September 30th. Two
people have commented. Nathan said that he wasn't sure this was best
(neither am I) but that he didn't have a better idea either (neither
do I). Stephen
On Sun, Oct 16, 2022 at 12:34 PM Stephen Frost wrote:
> As we work through splitting up the privileges and managing them in a
> more fine-grained way, it seems clear that we'll need to have a similar
> split for ADMIN rights on roles- that is, we'll need to be able to
> say "role X is allowed to
On Wed, Oct 12, 2022 at 4:59 PM Nathan Bossart wrote:
> I'm not sure about tying the ownership stuff to this new SET privilege.
> While you noted some practical advantages, I'd expect users to find it kind
> of surprising. Also, for predefined roles, I think you need to be careful
> about
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Fri, Sep 30, 2022 at 04:34:32PM -0400, Robert Haas wrote:
> > That thread has not reached an entirely satisfying conclusion.
> > However, the behavior that was deemed outright buggy over there has
> > been fixed. The remaining
On Fri, Sep 30, 2022 at 04:34:32PM -0400, Robert Haas wrote:
> That thread has not reached an entirely satisfying conclusion.
> However, the behavior that was deemed outright buggy over there has
> been fixed. The remaining question is what to do about commands that
> allow you to give objects to
On Wed, Aug 31, 2022 at 8:56 AM Robert Haas wrote:
> In order to apply this patch, we'd need to reach a conclusion about
> the matters mentioned in
> http://postgr.es/m/ca+tgmobheyynw9vrhvolvd8odspbjuu9cbk6tms6owd70hf...@mail.gmail.com
> -- and thinking about this patch might shed some light on
On Mon, Sep 12, 2022 at 11:41 AM Peter Eisentraut
wrote:
> I think this is because we have (erroneously) make SET ROLE to be the
> same as SET SESSION AUTHORIZATION. If those two were separate (i.e.,
> there is a current user and a separate current role, as in the SQL
> standard), then this
On 31.08.22 14:56, Robert Haas wrote:
In some circumstances, it may be desirable to control this behavior.
For example, if we GRANT pg_read_all_settings TO seer, we do want the
seer to be able to read all the settings, else we would not have
granted the role. But we might not want the seer to be
On Tue, Sep 6, 2022 at 2:45 PM Jeff Davis wrote:
> > I'm not sure whether thinking about this in terms of security
> > capabilities is the most helpful way to view it. My view was, as you
> > say, more mechanical. I think sometimes you grant somebody a role and
> > you want them to be able to use
On Tue, 2022-09-06 at 10:42 -0400, Robert Haas wrote:
> I think there are some other implications, but I don't think they're
> anything super-dramatic. For example, you could create a group that's
> just for purposes of pg_hba.conf matching and make the grants both
> SET
> FALSE and INHERIT FALSE,
On Sat, Sep 3, 2022 at 3:46 PM Jeff Davis wrote:
> > You are now connected to database "rhaas" as user "rhaas".
> > rhaas=# grant pg_read_all_settings to seer with set false;
> > GRANT ROLE
>
> You've defined this in terms of the mechanics -- allow SET ROLE or not
> -- but I assume you intend it
On Wed, 2022-08-31 at 08:56 -0400, Robert Haas wrote:
> In some circumstances, it may be desirable to control this behavior.
> For example, if we GRANT pg_read_all_settings TO seer, we do want the
> seer to be able to read all the settings, else we would not have
> granted the role. But we might
On Fri, Sep 2, 2022 at 3:20 AM Wolfgang Walther wrote:
> The full syntax could look like this:
>
> GRANT { INHERIT | SET | ALL [ PRIVILEGES ] }
>ON ROLE role_name [, ...]
>TO role_specification [, ...] WITH GRANT OPTION
>[ GRANTED BY role_specification ]
>
> With this new syntax, the
Robert Haas:
Beginning in
e3ce2de09d814f8770b2e3b3c152b7671bcdb83f, the inheritance behavior of
role-grants can be overridden for individual grants, so that some
grants are inherited and others are not.
That's a great thing to have!
However, there is no similar
facility for controlling
On Wed, Aug 31, 2022 at 08:56:31AM -0400, Robert Haas wrote:
> In some circumstances, it may be desirable to control this behavior.
> For example, if we GRANT pg_read_all_settings TO seer, we do want the
> seer to be able to read all the settings, else we would not have
> granted the role. But we
Hi,
There are two ways in which a role can exercise the privileges of some
other role which has been granted to it. First, it can implicitly
inherit the privileges of the granted role. Second, it can assume the
identity of the granted role using the SET ROLE command. It is
possible to control the
46 matches
Mail list logo
