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
>
Hi,
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
DML on system catalogs is
12 matches
Mail list logo
