On Tue, Jul 26, 2022 at 2:59 PM Tom Lane wrote:
> I had not actually read the patch, but now that I have, it's got
> a basic typing error:
>
> + boolshould_be_super = BoolGetDatum(boolVal(dissuper->arg));
> +
> + if (!should_be_super && roleid == BOOTSTRAP_SUPERUSERID)
> +
Robert Haas writes:
> Reaction to this patch seems tentatively positive so far, so I have
> committed it. Maybe someone will still show up to complain ... but I
> think it's a good change, so I hope not.
I had not actually read the patch, but now that I have, it's got
a basic typing error:
+
On Thu, Jul 21, 2022 at 1:27 PM Nathan Bossart wrote:
> Given the current assumptions the code makes about the bootstrap superuser,
> I think it makes sense to disallow removing its superuser attribute (at
> least via ALTER ROLE NOSUPERUSER). It seems like there is much work to do
> before a no-s
On Fri, Jul 22, 2022 at 1:21 PM Joe Conway wrote:
> My strategy has been to ensure no other roles are members of the
> bootstrap superuser role, and then alter the bootstrap user to be
> NOLOGIN. E.g. in the example here:
Yeah, making the bootstrap role NOLOGIN seems more reasonable than
making i
On 7/21/22 12:46, Tom Lane wrote:
"David G. Johnston" writes:
On Thu, Jul 21, 2022 at 9:28 AM Tom Lane wrote:
True, but what if the idea is to have *no* superusers? I seem
to recall people being interested in setups like that.
I would expect an initdb option (once this is possible) to spe
On Thu, Jul 21, 2022 at 01:02:50PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> ... if
>> we want to regard no-superusers as a supported configuration, we
>> probably need to tighten that up. I think it's kind of hopeless,
>
> Yeah, I agree. At least, I'm uninterested in spending any of my
>
Robert Haas writes:
> ... if
> we want to regard no-superusers as a supported configuration, we
> probably need to tighten that up. I think it's kind of hopeless,
Yeah, I agree. At least, I'm uninterested in spending any of my
own time trying to make that usefully-more-secure than it is today.
I
On Thu, Jul 21, 2022 at 12:28 PM Tom Lane wrote:
> True, but what if the idea is to have *no* superusers? I seem
> to recall people being interested in setups like that.
Hmm, right. There's nothing that stops you from de-super-ing all of
your superusers today, and then if you ever need to do any
"David G. Johnston" writes:
> On Thu, Jul 21, 2022 at 9:28 AM Tom Lane wrote:
>> True, but what if the idea is to have *no* superusers? I seem
>> to recall people being interested in setups like that.
> I would expect an initdb option (once this is possible) to specify this
> desire and we just
On Thu, Jul 21, 2022 at 9:28 AM Tom Lane wrote:
> Robert Haas writes:
> > Currently, it's possible to remove the rolissuper bit from the
> > bootstrap superuser, but this leaves that user - and the system in
> > general - in an odd state. The bootstrap user continues to own all of
> > the object
Robert Haas writes:
> Currently, it's possible to remove the rolissuper bit from the
> bootstrap superuser, but this leaves that user - and the system in
> general - in an odd state. The bootstrap user continues to own all of
> the objects it owned before, e.g. all of the system catalogs. Direct
>
11 matches
Mail list logo
