I wrote:
> Stephen Frost writes:
>> On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote:
>>> On the other hand, there's the point that lots of people have probably
>>> given out schema-CREATE privilege to users whom they wouldn't necessarily
>>> wish to trust with INSTALL privilege. Schema-CREATE is a
Stephen Frost writes:
> On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote:
>> On the other hand, there's the point that lots of people have probably
>> given out schema-CREATE privilege to users whom they wouldn't necessarily
>> wish to trust with INSTALL privilege. Schema-CREATE is a pretty harmless
Greetings,
On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
> >> I continue to think that allowing DB owners to decide this is, if not
> >> fundamentally the wrong thing, at least not a feature that anybody has
> >> asked f
Robert Haas writes:
> On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
>> I continue to think that allowing DB owners to decide this is, if not
>> fundamentally the wrong thing, at least not a feature that anybody has
>> asked for in the past. The feature *I* want in this area is for the
>> super
On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
> I continue to think that allowing DB owners to decide this is, if not
> fundamentally the wrong thing, at least not a feature that anybody has
> asked for in the past. The feature *I* want in this area is for the
> superuser to be able to decide w
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The minimum committable patch seems like it would just grant the
>> "can install trusted extensions" ability to DB owners, full stop.
> If you're alright with making it something a DB owner can do, what is
> the issue with making i
On Tue, Jan 28, 2020 at 3:29 PM Stephen Frost wrote:
> I get that you want to push forward with making this part of the DB
> owner, and I said up-thread that I'd be able to live with that, but I
> still don't understand what the argument is against making it part of
> CREATE instead.
It's a chang
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> The patch as I'm proposing it has nothing to do with "CREATE" rights.
> >> You're attacking something different from what I actually want to do.
>
> > Yes, as an aside, I'm a
On Tue, Jan 21, 2020 at 12:40 PM Tom Lane wrote:
> Given the lack of consensus about either of those being what we want,
> it doesn't seem like we're going to come to an agreement in a
> reasonable timeframe on a patch that includes either. So I'd like
> to get this done and move on to the next p
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The patch as I'm proposing it has nothing to do with "CREATE" rights.
>> You're attacking something different from what I actually want to do.
> Yes, as an aside, I'm argueing that we should split up the general
> CREATE privileges
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> In the meantime, though, this idea as stated doesn't do anything except
> >> let a DB owner grant install privileges to someone else. I'm not even
> >> convinced that we want
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In the meantime, though, this idea as stated doesn't do anything except
>> let a DB owner grant install privileges to someone else. I'm not even
>> convinced that we want that, or that anyone needs it (I can recall zero
>> such req
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or
> > 'CREATE EXTENSION' if we could make that work), so that we have it be
> > distinct from CREATE (which, today, really means 'CREATE SCHEMA').
>
Stephen Frost writes:
> To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or
> 'CREATE EXTENSION' if we could make that work), so that we have it be
> distinct from CREATE (which, today, really means 'CREATE SCHEMA').
I still say this is wrong, or at least pointless, because i
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 2:40 PM Tom Lane wrote:
> > Well, the other direction we could go here, which I guess is what
> > you are arguing for, is to forget the new default role and just
> > say that marking an extension trusted allows it t
On Fri, Jan 10, 2020 at 2:40 PM Tom Lane wrote:
> Well, the other direction we could go here, which I guess is what
> you are arguing for, is to forget the new default role and just
> say that marking an extension trusted allows it to be installed by
> DB owners, full stop. That's nice and simple
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Don't see how this follows. It's somewhat accidental I think that
>> the existing behavior is tied to DB ownership. That's just because
>> at the time, that's the only sort of privilege we had that seemed
>> intermediate between s
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > ... and that backs up my position that we are setting up this
> > privilege at the wrong level by using a default role which a superuser must
> > grant independently from DB ownership.
>
> Don't see how this follows. It's somewhat accidental
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > So I'm at a loss for why there is this insistence on a default role and
> > a superuser-explicit-granting based approach that goes beyond "is it
> > installed on the filesystem?" and "is it marked as trusted?".
>
> Oka
On Thu, Jan 9, 2020 at 3:18 PM Tom Lane wrote:
> * ISTM that that's assuming that the DBA and the sysadmin are the same
> person (or at least hold identical views on this subject). In many
> installations it'd only be root who has control over what's in that
> directory, and I don't think it's un
Stephen Frost writes:
> I am not particularly concerned about that backwards compatibility issue
> and I don’t intend to base my argument on it, but I would use that case to
> point out that we have long had the ability to install trusted C functions
> into the backend as a DB owner, without compl
Greetings,
On Thu, Jan 9, 2020 at 14:48 Tom Lane wrote:
> Robert Haas writes:
> > So, if I understand correctly, the patch you are proposing to commit
> > has a new system role, and if you've got that system role, then you
> > can install extensions.
>
> Install *trusted* extensions, correct.
Stephen Frost writes:
> So I'm at a loss for why there is this insistence on a default role and
> a superuser-explicit-granting based approach that goes beyond "is it
> installed on the filesystem?" and "is it marked as trusted?".
Okay, so it seems like we're down to just this one point of conten
On Thu, Jan 9, 2020 at 2:48 PM Tom Lane wrote:
> I agree that if we dropped the proviso about DB owners, it would be
> a cleaner design. I included that only for backwards compatibility
> with the existing behavior that DB owners can install trusted PLs.
> If we can agree that we're willing to lo
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 1:35 PM Tom Lane wrote:
> > Robert Haas writes:
> > > Again, as I said upthread, Tom had the exact feature about which I am
> > > talking in the first version of the patch. That is a strong argument
> > > in favor o
Robert Haas writes:
> So, if I understand correctly, the patch you are proposing to commit
> has a new system role, and if you've got that system role, then you
> can install extensions.
Install *trusted* extensions, correct. The patch as it stands also
allows DB owners to install trusted extens
On Thu, Jan 9, 2020 at 1:35 PM Tom Lane wrote:
> Robert Haas writes:
> > Again, as I said upthread, Tom had the exact feature about which I am
> > talking in the first version of the patch. That is a strong argument
> > in favor of it being practical. It's also a pretty good argument that
> > it
Robert Haas writes:
> Again, as I said upthread, Tom had the exact feature about which I am
> talking in the first version of the patch. That is a strong argument
> in favor of it being practical. It's also a pretty good argument that
> it is at least potentially useful, because Tom doesn't usuall
On Thu, Jan 9, 2020 at 11:30 AM Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Jan 9, 2020 at 10:09 AM Stephen Frost wrote:
> > > [ wall of text ]
>
> This really isn't helpful.
Sorry.
That being said, I'm pretty tired of writing emails that say the same
thing o
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 10:09 AM Stephen Frost wrote:
> > [ wall of text ]
This really isn't helpful.
> I don't see anything in here I really disagree with, but nor do I
> understand why any of it means that giving superusers the ability
On Thu, Jan 9, 2020 at 10:09 AM Stephen Frost wrote:
> [ wall of text ]
I don't see anything in here I really disagree with, but nor do I
understand why any of it means that giving superusers the ability to
customize which extensions are database-owner-installable would be a
bad thing.
> > I don
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 8, 2020 at 6:09 PM Stephen Frost wrote:
> > > To me, this seems more accidental than the natural fallout of good design.
> >
> > I disagree that the privilege design for FDWs was accidental.
>
> That seems like a stronger stat
On Wed, Jan 8, 2020 at 6:09 PM Stephen Frost wrote:
> > To me, this seems more accidental than the natural fallout of good design.
>
> I disagree that the privilege design for FDWs was accidental.
That seems like a stronger statement than the one I made...
> What I see differently is that the pu
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 7:32 PM Stephen Frost wrote:
> > You raised the point regarding postgres_fdw and a DB owner being able to
> > run 'create extension postgres_fdw;' and to then make network
> > connections, but that's proven to be inv
On Tue, Jan 7, 2020 at 7:32 PM Stephen Frost wrote:
> You raised the point regarding postgres_fdw and a DB owner being able to
> run 'create extension postgres_fdw;' and to then make network
> connections, but that's proven to be invalid because, assuming we make
> postgres_fdw trustable, we will
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 4:36 PM Stephen Frost wrote:
> > Here's the thing though.. creating the extension isn't *really* (in our
> > permissions model anyway) what lets you create outbound connections-
> > it's creating a 'SERVER', and to
On Tue, Jan 7, 2020 at 4:36 PM Stephen Frost wrote:
> Here's the thing though.. creating the extension isn't *really* (in our
> permissions model anyway) what lets you create outbound connections-
> it's creating a 'SERVER', and to be able to do that you need to have
> USAGE rights on the FDW, wh
Greetings!
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 7, 2020 at 1:17 PM Stephen Frost wrote:
> > Why would it be trusted if it's $SCARY_EXTENSION ...? Why are we trying
> > to punt on solving for that question by installing a much more
> > complicated system here than is really
On Tue, Jan 7, 2020 at 1:17 PM Stephen Frost wrote:
> Why would it be trusted if it's $SCARY_EXTENSION ...? Why are we trying
> to punt on solving for that question by installing a much more
> complicated system here than is really necessary, just to avoid having
> to make that decision?
I'm not
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 6, 2020 at 6:56 PM Stephen Frost wrote:
> > The first is this- ANYONE can create an extension in the system today,
> > if it's marked as superuser=false. If anything, it seems like that's
> > probably too loose- certainly base
On Mon, Jan 6, 2020 at 6:56 PM Stephen Frost wrote:
> The first is this- ANYONE can create an extension in the system today,
> if it's marked as superuser=false. If anything, it seems like that's
> probably too loose- certainly based on your contention that ONLY
> superusers should wield such a p
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I'm wrong, but I wouldn't think changing this from a
> > default-role based approach over to a GRANT'able right using our
> > existing GRANT system would be a lot of work.
>
> Nobody has proposed a GRANT-based
Stephen Frost writes:
> Perhaps I'm wrong, but I wouldn't think changing this from a
> default-role based approach over to a GRANT'able right using our
> existing GRANT system would be a lot of work.
Nobody has proposed a GRANT-based API that seems even close to
acceptable from where I sit. A ne
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
> >> After sleeping on it, I'm liking that idea; it's simple, and it
> >> preserves the existing behavior that DB owners can install trusted PLs
> >> without any extra permi
Robert Haas writes:
> On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
>> After sleeping on it, I'm liking that idea; it's simple, and it
>> preserves the existing behavior that DB owners can install trusted PLs
>> without any extra permissions. Now, if we follow this up by marking
>> most of cont
On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
> So, is that actually an objection to the current proposal, or just
> an unrelated rant?
Well, you brought up the topic of remaining bits in the context of the
proposal, so I guess it's related. And I said pretty clearly that it
wasn't necessarily a
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
> >> I do not agree that we should just shift to using default roles instead
> >> of adding new options to GRANT because of an entirely internal
> >> implementation det
Robert Haas writes:
> On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
>> I do not agree that we should just shift to using default roles instead
>> of adding new options to GRANT because of an entirely internal
>> implementation detail that we could fix (and should, as I've said for
>> probab
On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
> I do not agree that we should just shift to using default roles instead
> of adding new options to GRANT because of an entirely internal
> implementation detail that we could fix (and should, as I've said for
> probably 10 years now...).
+1.
I wrote:
> The cfbot noticed that a couple of patches committed this week
> created (trivial) conflicts with this patchset. Here's a v3
> rebased up to HEAD; no interesting changes.
The 2020 copyright update broke this patchset again. Here's a rebase.
No changes except for some minor rearrangeme
I wrote:
> Accordingly, here's a patchset that does it like that.
The cfbot noticed that a couple of patches committed this week
created (trivial) conflicts with this patchset. Here's a v3
rebased up to HEAD; no interesting changes.
regards, tom lane
diff --git a/doc/src
I wrote:
> Stephen Frost writes:
>> Really? Why do you think that DB ownership shouldn't be enough for
>> this, for trusted extensions?
> DB owners have never been particularly highly privileged in the past.
> I think that suddenly saying they can install extensions is moving
> the understanding
Chapman Flack writes:
> So isn't this more a proposal to add another boolean attribute
> to pg_authid, along the lines of rolcreatedb or rolbypassrls?
I think we've mostly concluded that default roles are superior
to pg_authid attributes. The latter are legacy things rather
than a model to keep
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>>> Two things- first, this doesn't actually cover everything that the
>>> proposed GUCs do- specifically, the proposed GUCs give you a way to
>>> limit what specific extensions are allowed to be installed, an
On 11/7/19 2:13 PM, Stephen Frost wrote:
>> That doesn't seem like a big objection from here. We could fix it
>> by making a separate privilege bit, but I doubt that it's worth using
>> up one of our limited set of spare bits for.
>
> I do not agree that we should just shift to using default rol
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> >> Peter Eisentraut writes:
> >>> Using GUCs to control some of this creates yet another place where
> >>> permission information is kept, and with it questions about how to get
> >>> to it, how to edit it, or to back
Stephen Frost writes:
>> Peter Eisentraut writes:
>>> Using GUCs to control some of this creates yet another place where
>>> permission information is kept, and with it questions about how to get
>>> to it, how to edit it, or to back it up and restore it, etc. Also,
>>> list-based parameters
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 2019-08-21 21:29, Tom Lane wrote:
> >> Patch 0001 below addresses this problem by inventing a concept of
> >> "trustable" (not necessarily trusted) extensions. An extension that
> >> would normally require superu
Peter Eisentraut writes:
> On 2019-08-21 21:29, Tom Lane wrote:
>> Patch 0001 below addresses this problem by inventing a concept of
>> "trustable" (not necessarily trusted) extensions. An extension that
>> would normally require superuser permissions (e.g., because it creates
>> C functions) can
On 2019-08-21 21:29, Tom Lane wrote:
Patch 0001 below addresses this problem by inventing a concept of
"trustable" (not necessarily trusted) extensions. An extension that
would normally require superuser permissions (e.g., because it creates
C functions) can now be installed by a non-superuser i
We've repeatedly kicked around the idea of getting rid of the
pg_pltemplate catalog in favor of keeping that information directly in
the languages' extension files [1][2][3][4]. The primary abstract
argument for that is that it removes a way in which our in-tree PLs
are special compared to out-of-
61 matches
Mail list logo
