Hi,
Chiming in as one of said providers...
> On Sat, 2025-04-05 at 19:07 -0400, Tom Lane wrote:
> > I took another look at this patch, and I still can't persuade
> > myself that a good case has been made for it. There are too
> > many scenarios where pg_manage_extensions would be a security
> > p
On Sat, 2025-04-05 at 19:07 -0400, Tom Lane wrote:
> I took another look at this patch, and I still can't persuade
> myself that a good case has been made for it. There are too
> many scenarios where pg_manage_extensions would be a security
> problem and too few where it seems to really improve ma
I took another look at this patch, and I still can't persuade
myself that a good case has been made for it. There are too
many scenarios where pg_manage_extensions would be a security
problem and too few where it seems to really improve manageability.
As an example, it was asserted upthread that
On Fri, Mar 7, 2025 at 11:21 AM Tom Lane wrote:
> While I'm all for chipping away at what superuser privilege is
> needed for, we have to tread VERY carefully about chipping away
> at things that allow any outside-the-database access.
I agree, but I also don't want the security decisions that the
Robert Haas writes:
> On Fri, Mar 7, 2025 at 9:37 AM Michael Banck wrote:
>> Also, I think there is case to be made that a cloud provider (or site
>> admin) would like to delegate the decision whether users with CREATE
>> rights on a particular database are allowed to install some extensions
>> o
Jelte Fennema-Nio writes:
> The reason why I walked back my comment was that cloud providers can
> simply choose which extensions they actually add to the image. If an
> extension is marked as not trusted by the author, then with this role
> they can still choose to add it without having to make c
On Fri, Mar 7, 2025 at 9:37 AM Michael Banck wrote:
> Also, I think there is case to be made that a cloud provider (or site
> admin) would like to delegate the decision whether users with CREATE
> rights on a particular database are allowed to install some extensions
> or not. Or rather, assign so
On Fri, 7 Mar 2025 at 15:37, Michael Banck wrote:
> On Fri, Mar 07, 2025 at 09:17:46AM -0500, Robert Haas wrote:
> > Why wouldn't the cloud provider just change add 'trusted = true' to
> > the relevant control files instead of doing this?
>
> That would be possible, but maybe the cloud provider i
Hi,
On Fri, Mar 07, 2025 at 09:17:46AM -0500, Robert Haas wrote:
> Why wouldn't the cloud provider just change add 'trusted = true' to
> the relevant control files instead of doing this?
That would be possible, but maybe the cloud provider is using
distribution packages and does not want to muck
On Fri, 2025-03-07 at 09:17 -0500, Robert Haas wrote:
> On Fri, Mar 7, 2025 at 9:02 AM Jelte Fennema-Nio wrote:
> > The reason why I walked back my comment was that cloud providers can
> > simply choose which extensions they actually add to the image. If an
> > extension is marked as not trusted b
On Fri, Mar 7, 2025 at 9:02 AM Jelte Fennema-Nio wrote:
> The reason why I walked back my comment was that cloud providers can
> simply choose which extensions they actually add to the image. If an
> extension is marked as not trusted by the author, then with this role
> they can still choose to a
On Fri, 7 Mar 2025 at 14:58, Robert Haas wrote:
> I see that Jelte walked this comment back, but I think this issue
> needs more discussion. I'm not intrinsically against having a role
> like pg_execute_server_programs that allows escalation to superuser,
> but I don't see how it would help a clou
On Fri, Jan 12, 2024 at 10:13 AM Jelte Fennema-Nio wrote:
> On Fri, 12 Jan 2024 at 15:53, Michael Banck wrote:
> > I propose to add a new predefined role to Postgres,
> > pg_manage_extensions. The idea is that it allows Superusers to delegate
> > the rights to create, update or delete extensions
Laurenz Albe writes:
> On Fri, 2025-02-28 at 19:16 +0100, Michael Banck wrote:
>> New version 3 attached.
>
> I am fine with v3, and I'll mark it "ready for committer".
>
> I have been wondering about regression tests.
> We cannot have them in the core tests, because we cannot rely on any
> exten
On Fri, 2025-02-28 at 19:16 +0100, Michael Banck wrote:
> New version 3 attached.
I am fine with v3, and I'll mark it "ready for committer".
I have been wondering about regression tests.
We cannot have them in the core tests, because we cannot rely on any
extension being available.
We could shove
Hi,
On Fri, Jan 17, 2025 at 10:03:17AM +0100, Laurenz Albe wrote:
> On Thu, 2024-10-31 at 22:47 +0100, Michael Banck wrote:
> > Even though there has not been a lot of discussion on this, here is a
> > rebased patch. I have also added it to the upcoming commitfest.
>
> I had a look at the patch.
On Thu, 2024-10-31 at 22:47 +0100, Michael Banck wrote:
> Even though there has not been a lot of discussion on this, here is a
> rebased patch. I have also added it to the upcoming commitfest.
I had a look at the patch.
> --- a/doc/src/sgml/user-manag.sgml
> +++ b/doc/src/sgml/user-manag.sgml
>
Hi,
On Thu, Jan 16, 2025 at 04:09:44PM +0900, Shinya Kato wrote:
> On Thu, Jan 16, 2025 at 3:31 PM Michael Banck wrote:
> > I do think having a whitelist of allowed-to-be-installed extensions
> > (similar/like https://github.com/dimitri/pgextwlist) makes sense
> > additionally in today's containe
On Thu, Jan 16, 2025 at 3:31 PM Michael Banck wrote:
I agree with this idea.
I think it is natural to delegate a part of superuser privileges to
another role because superuser privilege is too strong.
> > In general, this concept is rather dubious. Why should we have such a
> > dangerous pre-def
Hi,
first, sorry for the late reply :-/
On Mon, Nov 18, 2024 at 11:26:40AM +0500, Kirill Reshke wrote:
> On Fri, 1 Nov 2024 at 02:47, Michael Banck wrote:
> > Even though there has not been a lot of discussion on this, here is a
> > rebased patch. I have also added it to the upcoming commitfest
On Mon, 18 Nov 2024 at 11:26, Kirill Reshke wrote:
>
> On Fri, 1 Nov 2024 at 02:47, Michael Banck wrote:
> >
> > Hi,
> >
> > Even though there has not been a lot of discussion on this, here is a
> > rebased patch. I have also added it to the upcoming commitfest.
>
>
> Hi!
>
> > + pg_manage
On Fri, 1 Nov 2024 at 02:47, Michael Banck wrote:
>
> Hi,
>
> Even though there has not been a lot of discussion on this, here is a
> rebased patch. I have also added it to the upcoming commitfest.
Hi!
> + pg_manage_extensions allows creating, removing or
> + updating extensions, e
On Thu, 31 Oct 2024 at 22:47, Michael Banck wrote:
> Even though there has not been a lot of discussion on this, here is a
> rebased patch. I have also added it to the upcoming commitfest.
After considering this again, I actually think this is a good change.
Basically all cloud providers already
Hi,
Even though there has not been a lot of discussion on this, here is a
rebased patch. I have also added it to the upcoming commitfest.
On Sat, Jan 13, 2024 at 09:20:40AM +0100, Michael Banck wrote:
> On Fri, Jan 12, 2024 at 04:13:27PM +0100, Jelte Fennema-Nio wrote:
> > But I'm not sure that
Hi,
On Fri, Jan 12, 2024 at 04:13:27PM +0100, Jelte Fennema-Nio wrote:
> But I'm not sure that such a pg_manage_extensions role would have any
> fewer permissions than superuser in practice.
Note that just being able to create an extension does not give blanket
permission to use it. I did a few
On Fri, 12 Jan 2024 at 15:53, Michael Banck wrote:
> I propose to add a new predefined role to Postgres,
> pg_manage_extensions. The idea is that it allows Superusers to delegate
> the rights to create, update or delete extensions to other roles, even
> if those extensions are not trusted or those
Hi,
I propose to add a new predefined role to Postgres,
pg_manage_extensions. The idea is that it allows Superusers to delegate
the rights to create, update or delete extensions to other roles, even
if those extensions are not trusted or those users are not the database
owner.
I have attached a W
27 matches
Mail list logo
