public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v16 03/10] Add tests on pg_ls_dir before changing it
8+ messages / 6 participants
[nested] [flat]
* [PATCH v16 03/10] Add tests on pg_ls_dir before changing it
@ 2020-03-17 18:16 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 8+ messages in thread
From: Justin Pryzby @ 2020-03-17 18:16 UTC (permalink / raw)
---
src/test/regress/expected/misc_functions.out | 18 ++++++++++++++++++
src/test/regress/sql/misc_functions.sql | 5 +++++
2 files changed, 23 insertions(+)
diff --git a/src/test/regress/expected/misc_functions.out b/src/test/regress/expected/misc_functions.out
index d3acb98d04..2e87c548eb 100644
--- a/src/test/regress/expected/misc_functions.out
+++ b/src/test/regress/expected/misc_functions.out
@@ -201,6 +201,24 @@ select count(*) > 0 from
t
(1 row)
+select * from (select pg_ls_dir('.', false, true) as name) as ls where ls.name='.'; -- include_dot_dirs=true
+ name
+------
+ .
+(1 row)
+
+select * from (select pg_ls_dir('.', false, false) as name) as ls where ls.name='.'; -- include_dot_dirs=false
+ name
+------
+(0 rows)
+
+select pg_ls_dir('does not exist', true, false); -- ok with missingok=true
+ pg_ls_dir
+-----------
+(0 rows)
+
+select pg_ls_dir('does not exist'); -- fails with missingok=false
+ERROR: could not open directory "does not exist": No such file or directory
--
-- Test adding a support function to a subject function
--
diff --git a/src/test/regress/sql/misc_functions.sql b/src/test/regress/sql/misc_functions.sql
index 094e8f8296..f6857ad177 100644
--- a/src/test/regress/sql/misc_functions.sql
+++ b/src/test/regress/sql/misc_functions.sql
@@ -60,6 +60,11 @@ select count(*) > 0 from
where spcname = 'pg_default') pts
join pg_database db on pts.pts = db.oid;
+select * from (select pg_ls_dir('.', false, true) as name) as ls where ls.name='.'; -- include_dot_dirs=true
+select * from (select pg_ls_dir('.', false, false) as name) as ls where ls.name='.'; -- include_dot_dirs=false
+select pg_ls_dir('does not exist', true, false); -- ok with missingok=true
+select pg_ls_dir('does not exist'); -- fails with missingok=false
+
--
-- Test adding a support function to a subject function
--
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0004-Add-pg_ls_dir_metadata-to-list-a-dir-with-file-m.patch"
^ permalink raw reply [nested|flat] 8+ messages in thread
* Possibility to disable `ALTER SYSTEM`
@ 2023-09-07 19:51 Gabriele Bartolini <[email protected]>
2023-09-07 19:57 ` Re: Possibility to disable `ALTER SYSTEM` Joe Conway <[email protected]>
2023-09-07 20:27 ` Re: Possibility to disable `ALTER SYSTEM` Tom Lane <[email protected]>
2023-09-08 23:24 ` Re: Possibility to disable `ALTER SYSTEM` Álvaro Hernández <[email protected]>
2024-01-30 17:05 ` Re: Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
0 siblings, 4 replies; 8+ messages in thread
From: Gabriele Bartolini @ 2023-09-07 19:51 UTC (permalink / raw)
To: pgsql-hackers
Hi everyone,
I would like to propose a patch that allows administrators to disable
`ALTER SYSTEM` via either a runt-time option to pass to the Postgres server
process at startup (e.g. `--disable-alter-system=true`, false by default)
or a new GUC (or even both), without changing the current default method of
the server.
The main reason is that this would help improve the “security by default”
posture of Postgres in a Kubernetes/Cloud Native environment - and, in
general, in any environment on VMs/bare metal behind a configuration
management system in which changes should only be made in a declarative way
and versioned like Ansible Tower, to cite one.
Below you find some background information and the longer story behind this
proposal.
Sticking to the Kubernetes use case, I am primarily speaking on behalf of
the CloudNativePG open source operator (cloudnative-pg.io, of which I am
one of the maintainers). However, I am sure that this option could benefit
any operator for Postgres - an operator is the most common and recommended
way to run a complex application like a PostgreSQL database management
system inside Kubernetes.
In this case, the state of a PostgreSQL cluster (for example its number of
replicas, configuration, storage, etc.) is defined in a Custom Resource
Definition in the form of configuration, typically YAML, and the operator
works with Kubernetes to ensure that, at any moment, the requested Postgres
cluster matches the observed one. This is a very basic example in
CloudNativePG:
https://cloudnative-pg.io/documentation/current/samples/cluster-example.yaml
As I was mentioning above, in a Cloud Native environment it is expected
that workloads are secure by default. Without going into much detail, many
decisions have been made in that direction by operators for Postgres,
including CloudNativePG. The goal of this proposal is to provide a way to
ensure that changes to the PostgreSQL configuration in a Kubernetes
controlled Postgres cluster are allowed only through the Kubernetes API.
Basically, if you want to change an option for PostgreSQL, you need to
change the desired state in the Kubernetes resource, then Kubernetes will
converge (through the operator). In simple words, it’s like empowering the
operator to impersonate the PostgreSQL superuser.
However, given that we cannot force this use case, there could be roles
with the login+superuser privileges connecting to the PostgreSQL instance
and potentially “interfering” with the requested state defined in the
configuration by imperatively running “ALTER SYSTEM” commands.
For example: CloudNativePG has a fixed value for some GUCs in order to
manage a full HA cluster, including SSL, log, some WAL and replication
settings. While the operator eventually reconciles those settings, even the
temporary change of those settings in a cluster might be harmful. Think for
example of a user that, through `ALTER SYSTEM`, tries to change WAL level
to minimal, or change the setting of the log (we require CSV), potentially
creating issues to the underlying instance and cluster (potentially leaving
it in an unrecoverable state in the case of other more invasive GUCS).
At the moment, a possible workaround is that `ALTER SYSTEM` can be blocked
by making the postgresql.auto.conf read only, but the returned message is
misleading and that’s certainly bad user experience (which is very
important in a cloud native environment):
```
postgres=# ALTER SYSTEM SET wal_level TO minimal;
ERROR: could not open file "postgresql.auto.conf": Permission denied
```
For this reason, I would like to propose the option to be given to the
postgres process at startup, in order to be as less invasive as possible
(the operator could then start Postgres requesting `ALTER SYSTEM` to be
disabled). That’d be my preference at the moment, if possible.
Alternatively, or in addition, the introduction of a GUC to disable `ALTER
SYSTEM` altogether. This enables tuning this setting through configuration
at the Kubernetes level, only if the operators require it - without
damaging the rest of the users.
Before I start writing any lines of code and propose a patch, I would like
first to understand if there’s room for it.
Thanks for your attention and … looking forward to your feedback!
Ciao,
Gabriele
--
Gabriele Bartolini
Vice President, Cloud Native at EDB
enterprisedb.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Possibility to disable `ALTER SYSTEM`
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
@ 2023-09-07 19:57 ` Joe Conway <[email protected]>
3 siblings, 0 replies; 8+ messages in thread
From: Joe Conway @ 2023-09-07 19:57 UTC (permalink / raw)
To: Gabriele Bartolini <[email protected]>; pgsql-hackers
On 9/7/23 15:51, Gabriele Bartolini wrote:
> I would like to propose a patch that allows administrators to disable
> `ALTER SYSTEM` via either a runt-time option to pass to the Postgres
> server process at startup (e.g. `--disable-alter-system=true`, false by
> default) or a new GUC (or even both), without changing the current
> default method of the server.
Without trying to debate the particulars, a huge +1 for the concept of
allowing ALTER SYSTEM to be disabled. FWIW I would vote the same for
control over COPY PROGRAM.
Not coincidentally both concepts were built into set_user:
https://github.com/pgaudit/set_user
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Possibility to disable `ALTER SYSTEM`
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
@ 2023-09-07 20:27 ` Tom Lane <[email protected]>
2023-09-08 11:31 ` Re: Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
3 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2023-09-07 20:27 UTC (permalink / raw)
To: Gabriele Bartolini <[email protected]>; +Cc: pgsql-hackers
Gabriele Bartolini <[email protected]> writes:
> I would like to propose a patch that allows administrators to disable
> `ALTER SYSTEM` via either a runt-time option to pass to the Postgres server
> process at startup (e.g. `--disable-alter-system=true`, false by default)
> or a new GUC (or even both), without changing the current default method of
> the server.
ALTER SYSTEM is already heavily restricted. I don't think we need random
kluges added to the permissions system. I especially don't believe in
kluges to the effect of "superuser doesn't have all permissions anymore".
If you nonetheless feel that that's a good idea for your use case,
you can implement the restriction with an event trigger or the like.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Possibility to disable `ALTER SYSTEM`
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
2023-09-07 20:27 ` Re: Possibility to disable `ALTER SYSTEM` Tom Lane <[email protected]>
@ 2023-09-08 11:31 ` Gabriele Bartolini <[email protected]>
2023-09-08 14:11 ` Re: Possibility to disable `ALTER SYSTEM` Isaac Morland <[email protected]>
0 siblings, 1 reply; 8+ messages in thread
From: Gabriele Bartolini @ 2023-09-08 11:31 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
Hi Tom,
On Thu, 7 Sept 2023 at 22:27, Tom Lane <[email protected]> wrote:
> Gabriele Bartolini <[email protected]> writes:
> > I would like to propose a patch that allows administrators to disable
> > `ALTER SYSTEM` via either a runt-time option to pass to the Postgres
> server
> > process at startup (e.g. `--disable-alter-system=true`, false by default)
> > or a new GUC (or even both), without changing the current default method
> of
> > the server.
>
> ALTER SYSTEM is already heavily restricted.
Could you please help me better understand what you mean here?
> I don't think we need random kluges added to the permissions system.
If you allow me, why do you think disabling ALTER SYSTEM altogether is a
random kluge? Again, I'd like to better understand this position. I've
personally been in many conversations on the security side of things for
Postgres in Kubernetes environments, and this is a frequent concern by
users who request that changes to the Postgres system (not a database)
should only be done declaratively and prevented from within the system.
Thanks,
Gabriele
--
Gabriele Bartolini
Vice President, Cloud Native at EDB
enterprisedb.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Possibility to disable `ALTER SYSTEM`
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
2023-09-07 20:27 ` Re: Possibility to disable `ALTER SYSTEM` Tom Lane <[email protected]>
2023-09-08 11:31 ` Re: Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
@ 2023-09-08 14:11 ` Isaac Morland <[email protected]>
0 siblings, 0 replies; 8+ messages in thread
From: Isaac Morland @ 2023-09-08 14:11 UTC (permalink / raw)
To: Gabriele Bartolini <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
On Fri, 8 Sept 2023 at 10:03, Gabriele Bartolini <
[email protected]> wrote:
> ALTER SYSTEM is already heavily restricted.
>
>
> Could you please help me better understand what you mean here?
>
>
>> I don't think we need random kluges added to the permissions system.
>
>
> If you allow me, why do you think disabling ALTER SYSTEM altogether is a
> random kluge? Again, I'd like to better understand this position. I've
> personally been in many conversations on the security side of things for
> Postgres in Kubernetes environments, and this is a frequent concern by
> users who request that changes to the Postgres system (not a database)
> should only be done declaratively and prevented from within the system.
>
Alternate idea, not sure how good this is: Use existing OS security
features (regular permissions, or more modern features such as the
immutable attribute) to mark the postgresql.auto.conf file as not being
writeable. Then any attempt to ALTER SYSTEM should result in an error.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Possibility to disable `ALTER SYSTEM`
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
@ 2023-09-08 23:24 ` Álvaro Hernández <[email protected]>
3 siblings, 0 replies; 8+ messages in thread
From: Álvaro Hernández @ 2023-09-08 23:24 UTC (permalink / raw)
To: Gabriele Bartolini <[email protected]>; pgsql-hackers
On 7/9/23 21:51, Gabriele Bartolini wrote:
> Hi everyone,
>
> I would like to propose a patch that allows administrators to disable
> `ALTER SYSTEM` via either a runt-time option to pass to the Postgres
> server process at startup (e.g. `--disable-alter-system=true`, false
> by default) or a new GUC (or even both), without changing the current
> default method of the server.
>
> The main reason is that this would help improve the “security by
> default” posture of Postgres in a Kubernetes/Cloud Native environment
> - and, in general, in any environment on VMs/bare metal behind a
> configuration management system in which changes should only be made
> in a declarative way and versioned like Ansible Tower, to cite one.
>
> Below you find some background information and the longer story behind
> this proposal.
>
> Sticking to the Kubernetes use case, I am primarily speaking on behalf
> of the CloudNativePG open source operator (cloudnative-pg.io
> <http://cloudnative-pg.io;, of which I am one of the maintainers).
> However, I am sure that this option could benefit any operator for
> Postgres - an operator is the most common and recommended way to run a
> complex application like a PostgreSQL database management system
> inside Kubernetes.
>
> In this case, the state of a PostgreSQL cluster (for example its
> number of replicas, configuration, storage, etc.) is defined in a
> Custom Resource Definition in the form of configuration, typically
> YAML, and the operator works with Kubernetes to ensure that, at any
> moment, the requested Postgres cluster matches the observed one. This
> is a very basic example in CloudNativePG:
> https://cloudnative-pg.io/documentation/current/samples/cluster-example.yaml
>
> As I was mentioning above, in a Cloud Native environment it is
> expected that workloads are secure by default. Without going into much
> detail, many decisions have been made in that direction by operators
> for Postgres, including CloudNativePG. The goal of this proposal is to
> provide a way to ensure that changes to the PostgreSQL configuration
> in a Kubernetes controlled Postgres cluster are allowed only through
> the Kubernetes API.
>
> Basically, if you want to change an option for PostgreSQL, you need to
> change the desired state in the Kubernetes resource, then Kubernetes
> will converge (through the operator). In simple words, it’s like
> empowering the operator to impersonate the PostgreSQL superuser.
>
Coming from a similar background to Gabriele's, I support this
proposal.
In StackGres (https://stackgres.io) we also allow users to manage
postgresql.conf's configuration declaratively. We have a CRD (Custom
Resource Definition) that precisely defines and controls how a
postgresql.conf configuration looks like (see
https://stackgres.io/doc/latest/reference/crd/sgpgconfig/). This
configuration, once created by the user, is strongly validated by
StackGres (parameters are valid for the given major version, values are
within the ranges and appropriate types) and then periodically applied
to the database if there's any drift between that user-declared
(desired) state and current system status.
Similarly, we also have some parameters which the user is not
allowed to change
(https://gitlab.com/ongresinc/stackgres/-/blob/main/stackgres-k8s/src/operator/src/main/resources/pos...).
If the user is allowed to use ALTER SYSTEM and modify some of these
parameters, significant breakage can happen in the cluster, as the
operator may become "confused" and manual operation may be required,
breaking many of the user's expectations of stability and how the system
works and heals automatically.
Sure, as mentioned elsewhere in the thread, a "malicious" user can
still use other mechanisms such as COPY or untrusted PLs to still
overwrite the configuration. But both attempts are obviously conscious
attempts to break the system (and if so, it's all yours to break it).
But ALTER SYSTEM may be an *unintended* way to break it, causing a bad
user's experience. This may be defined more of a way to avoid users
shooting themselves in the feet, inadvertedly.
There's apparently some opposition to implementing this. But given
that there's also interest in having it, I'd like to know what the
negative effects of implementing such a startup configuration property
would be, so that advantages can be compared with the disadvantages.
All that being said, the behavior to prevent ALTER SYSTEM can also
be easily implemented as an extension. Actually some colleagues wrote
one with a similar scope
(https://gitlab.com/ongresinc/extensions/noset), and I believe it could
be the base for a similar extension focused on preventing ALTER SYSTEM.
Regards,
Álvaro
--
Alvaro Hernandez
-----------
OnGres
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Possibility to disable `ALTER SYSTEM`
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
@ 2024-01-30 17:05 ` Gabriele Bartolini <[email protected]>
3 siblings, 0 replies; 8+ messages in thread
From: Gabriele Bartolini @ 2024-01-30 17:05 UTC (permalink / raw)
To: pgsql-hackers
Hi,
I am sending an updated patch, and submitting this to the next commit fest,
as I still believe this could be very useful.
Thanks,
Gabriele
On Thu, 7 Sept 2023 at 21:51, Gabriele Bartolini <
[email protected]> wrote:
> Hi everyone,
>
> I would like to propose a patch that allows administrators to disable
> `ALTER SYSTEM` via either a runt-time option to pass to the Postgres server
> process at startup (e.g. `--disable-alter-system=true`, false by default)
> or a new GUC (or even both), without changing the current default method of
> the server.
>
> The main reason is that this would help improve the “security by default”
> posture of Postgres in a Kubernetes/Cloud Native environment - and, in
> general, in any environment on VMs/bare metal behind a configuration
> management system in which changes should only be made in a declarative way
> and versioned like Ansible Tower, to cite one.
>
> Below you find some background information and the longer story behind
> this proposal.
>
> Sticking to the Kubernetes use case, I am primarily speaking on behalf of
> the CloudNativePG open source operator (cloudnative-pg.io, of which I am
> one of the maintainers). However, I am sure that this option could benefit
> any operator for Postgres - an operator is the most common and recommended
> way to run a complex application like a PostgreSQL database management
> system inside Kubernetes.
>
> In this case, the state of a PostgreSQL cluster (for example its number of
> replicas, configuration, storage, etc.) is defined in a Custom Resource
> Definition in the form of configuration, typically YAML, and the operator
> works with Kubernetes to ensure that, at any moment, the requested Postgres
> cluster matches the observed one. This is a very basic example in
> CloudNativePG:
> https://cloudnative-pg.io/documentation/current/samples/cluster-example.yaml
>
> As I was mentioning above, in a Cloud Native environment it is expected
> that workloads are secure by default. Without going into much detail, many
> decisions have been made in that direction by operators for Postgres,
> including CloudNativePG. The goal of this proposal is to provide a way to
> ensure that changes to the PostgreSQL configuration in a Kubernetes
> controlled Postgres cluster are allowed only through the Kubernetes API.
>
> Basically, if you want to change an option for PostgreSQL, you need to
> change the desired state in the Kubernetes resource, then Kubernetes will
> converge (through the operator). In simple words, it’s like empowering the
> operator to impersonate the PostgreSQL superuser.
>
> However, given that we cannot force this use case, there could be roles
> with the login+superuser privileges connecting to the PostgreSQL instance
> and potentially “interfering” with the requested state defined in the
> configuration by imperatively running “ALTER SYSTEM” commands.
>
> For example: CloudNativePG has a fixed value for some GUCs in order to
> manage a full HA cluster, including SSL, log, some WAL and replication
> settings. While the operator eventually reconciles those settings, even the
> temporary change of those settings in a cluster might be harmful. Think for
> example of a user that, through `ALTER SYSTEM`, tries to change WAL level
> to minimal, or change the setting of the log (we require CSV), potentially
> creating issues to the underlying instance and cluster (potentially leaving
> it in an unrecoverable state in the case of other more invasive GUCS).
>
> At the moment, a possible workaround is that `ALTER SYSTEM` can be blocked
> by making the postgresql.auto.conf read only, but the returned message is
> misleading and that’s certainly bad user experience (which is very
> important in a cloud native environment):
>
> ```
> postgres=# ALTER SYSTEM SET wal_level TO minimal;
> ERROR: could not open file "postgresql.auto.conf": Permission denied
> ```
>
> For this reason, I would like to propose the option to be given to the
> postgres process at startup, in order to be as less invasive as possible
> (the operator could then start Postgres requesting `ALTER SYSTEM` to be
> disabled). That’d be my preference at the moment, if possible.
>
> Alternatively, or in addition, the introduction of a GUC to disable `ALTER
> SYSTEM` altogether. This enables tuning this setting through configuration
> at the Kubernetes level, only if the operators require it - without
> damaging the rest of the users.
>
> Before I start writing any lines of code and propose a patch, I would like
> first to understand if there’s room for it.
>
> Thanks for your attention and … looking forward to your feedback!
>
> Ciao,
> Gabriele
> --
> Gabriele Bartolini
> Vice President, Cloud Native at EDB
> enterprisedb.com
>
--
Gabriele Bartolini
Vice President, Cloud Native at EDB
enterprisedb.com
Attachments:
[application/octet-stream] 0001-Add-enable_alter_system-GUC.patch (3.7K, ../../CA+VUV5rm86NGOEPc3bhqPsNWeWWWzyhVDBiE7EfoSKobAiTERg@mail.gmail.com/3-0001-Add-enable_alter_system-GUC.patch)
download | inline diff:
From fbc6bb367796a30bf857cbc4ef9b9097fa4d97e2 Mon Sep 17 00:00:00 2001
From: Gabriele Bartolini <[email protected]>
Date: Fri, 8 Sep 2023 20:25:36 +0200
Subject: [PATCH] Add `enable_alter_system` GUC
Introduce the `enable_alter_system` GUC (by default set to `true`)
to be configured as an option at startup of the postmaster.
Signed-off-by: Gabriele Bartolini <[email protected]>
---
doc/src/sgml/ref/alter_system.sgml | 6 ++++++
doc/src/sgml/ref/pg_ctl-ref.sgml | 9 +++++++++
src/backend/utils/misc/guc.c | 8 ++++++++
src/backend/utils/misc/guc_tables.c | 10 ++++++++++
src/include/utils/guc_tables.h | 3 +++
5 files changed, 36 insertions(+)
diff --git a/doc/src/sgml/ref/alter_system.sgml b/doc/src/sgml/ref/alter_system.sgml
index bea5714ba1..3e727d08da 100644
--- a/doc/src/sgml/ref/alter_system.sgml
+++ b/doc/src/sgml/ref/alter_system.sgml
@@ -111,6 +111,12 @@ ALTER SYSTEM RESET ALL
<para>
See <xref linkend="config-setting"/> for other ways to set the parameters.
</para>
+
+ <para>
+ <literal>ALTER SYSTEM</literal> can be disabled at startup by passing
+ <literal>enable_alter_system=off</literal> to the <command>postgres</command>
+ command.
+ </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/pg_ctl-ref.sgml b/doc/src/sgml/ref/pg_ctl-ref.sgml
index 46906966eb..f6d573084f 100644
--- a/doc/src/sgml/ref/pg_ctl-ref.sgml
+++ b/doc/src/sgml/ref/pg_ctl-ref.sgml
@@ -645,6 +645,15 @@ PostgreSQL documentation
<screen>
<prompt>$</prompt> <userinput>pg_ctl -o "-F -p 5433" start</userinput>
</screen></para>
+
+ <para>
+ To start the server and disable <command>ALTER SYSTEM</command>,
+ waiting until the server is accepting connections:
+<screen>
+<prompt>$</prompt> <userinput>pg_ctl start -o "-c enable_alter_system=off"</userinput>
+</screen>
+ </para>
+
</refsect2>
<refsect2 id="r2-app-pgctl-4">
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 8f65ef3d89..e1cd6f6f57 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4544,6 +4544,14 @@ AlterSystemSetConfigFile(AlterSystemStmt *altersysstmt)
*/
name = altersysstmt->setstmt->name;
+ if (! EnableAlterSystem)
+ {
+
+ ereport(ERROR,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ errmsg("permission denied to run ALTER SYSTEM")));
+ }
+
switch (altersysstmt->setstmt->kind)
{
case VAR_SET_VALUE:
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 7fe58518d7..2710b7d8e0 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -492,6 +492,7 @@ extern const struct config_enum_entry dynamic_shared_memory_options[];
/*
* GUC option variables that are exported from this module
*/
+bool EnableAlterSystem = true;
bool log_duration = false;
bool Debug_print_plan = false;
bool Debug_print_parse = false;
@@ -1085,6 +1086,15 @@ struct config_bool ConfigureNamesBool[] =
false,
NULL, NULL, NULL
},
+ {
+ {"enable_alter_system", PGC_POSTMASTER, UNGROUPED,
+ gettext_noop("Enable ALTER SYSTEM command"),
+ NULL
+ },
+ &EnableAlterSystem,
+ true,
+ NULL, NULL, NULL
+ },
{
{"bonjour", PGC_POSTMASTER, CONN_AUTH_SETTINGS,
gettext_noop("Enables advertising the server via Bonjour."),
diff --git a/src/include/utils/guc_tables.h b/src/include/utils/guc_tables.h
index 0a2e274ebb..b20eb58fd6 100644
--- a/src/include/utils/guc_tables.h
+++ b/src/include/utils/guc_tables.h
@@ -320,4 +320,7 @@ extern char *config_enum_get_options(struct config_enum *record,
const char *suffix,
const char *separator);
+/* GUC reference to enable/disable alter system */
+extern PGDLLIMPORT bool EnableAlterSystem;
+
#endif /* GUC_TABLES_H */
--
2.43.0
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2024-01-30 17:05 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-17 18:16 [PATCH v16 03/10] Add tests on pg_ls_dir before changing it Justin Pryzby <[email protected]>
2023-09-07 19:51 Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
2023-09-07 19:57 ` Re: Possibility to disable `ALTER SYSTEM` Joe Conway <[email protected]>
2023-09-07 20:27 ` Re: Possibility to disable `ALTER SYSTEM` Tom Lane <[email protected]>
2023-09-08 11:31 ` Re: Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
2023-09-08 14:11 ` Re: Possibility to disable `ALTER SYSTEM` Isaac Morland <[email protected]>
2023-09-08 23:24 ` Re: Possibility to disable `ALTER SYSTEM` Álvaro Hernández <[email protected]>
2024-01-30 17:05 ` Re: Possibility to disable `ALTER SYSTEM` Gabriele Bartolini <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox