allow building trusted languages without the untrusted versions

Nathan Bossart <nathandbossart@gmail.com> writes:

Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need
to make a couple of code changes to compile out the untrusted parts. I
suspect many users (e.g., anyone who wants to disallow file system access)
would benefit from a better supported way to do this. Thus, I've attached
some patches that introduce an optional argument for the --with-perl and
--with-tcl configuration options. This new argument can be used to build
only the trusted or untrusted version of the language. If the argument is
not provided, both the trusted and untrusted versions are built, so this
change is backward compatible.

I do not believe that this is worth the extra complication. Nobody has
ever asked for it before, so I estimate the number of people who would
use it as near zero, and those folk are entirely capable of removing
the relevant extension files from their installations.

Moreover, if we accept this as a useful configure option, what other
things will we be called on to change? It surely makes no sense to
install contrib/adminpack, for instance, if you're afraid of having
plperlu installed.

Lastly, you've offered no reason to think this would provide any real
security improvement. Someone who's gained the ability to issue CREATE
EXTENSION on untrusted extensions has already got all the privileges he
needs; leaving out a few extension files is at most going to slow him
down a bit on the way to full filesystem access. (See, eg, COPY TO
PROGRAM.)

regards, tom lane

On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need
to make a couple of code changes to compile out the untrusted parts. I
suspect many users (e.g., anyone who wants to disallow file system access)
would benefit from a better supported way to do this. Thus, I've attached
some patches that introduce an optional argument for the --with-perl and
--with-tcl configuration options. This new argument can be used to build
only the trusted or untrusted version of the language. If the argument is
not provided, both the trusted and untrusted versions are built, so this
change is backward compatible.

I do not believe that this is worth the extra complication. Nobody has
ever asked for it before, so I estimate the number of people who would
use it as near zero, and those folk are entirely capable of removing
the relevant extension files from their installations.

Of course, if there is no interest in this feature, I'll withdraw the patch
from consideration. However, I will note that moving the extension files
aside is not sufficient for blocking all use of untrusted languages, since
the symbols for their handler/validator functions will still be present.

Moreover, if we accept this as a useful configure option, what other
things will we be called on to change? It surely makes no sense to
install contrib/adminpack, for instance, if you're afraid of having
plperlu installed.

Lastly, you've offered no reason to think this would provide any real
security improvement. Someone who's gained the ability to issue CREATE
EXTENSION on untrusted extensions has already got all the privileges he
needs; leaving out a few extension files is at most going to slow him
down a bit on the way to full filesystem access. (See, eg, COPY TO
PROGRAM.)

I'd like to provide the ability to disallow these other things, too. This
is intended to be a first step in that direction.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Nathan Bossart <nathandbossart@gmail.com> writes:

On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:

Lastly, you've offered no reason to think this would provide any real
security improvement. Someone who's gained the ability to issue CREATE
EXTENSION on untrusted extensions has already got all the privileges he
needs; leaving out a few extension files is at most going to slow him
down a bit on the way to full filesystem access. (See, eg, COPY TO
PROGRAM.)

I'd like to provide the ability to disallow these other things, too. This
is intended to be a first step in that direction.

There would probably be some interest in a "--disable-disk-access"
configure option that did all of this stuff (and some more things
too), with the aim of locking down *all* known paths to filesystem
access. I don't see much value in retail options that do some of that.
In fact, what they might mostly accomplish is to give people a false
sense of security.

regards, tom lane

On Mon, May 23, 2022 at 01:17:08PM -0400, Tom Lane wrote:

There would probably be some interest in a "--disable-disk-access"
configure option that did all of this stuff (and some more things
too), with the aim of locking down *all* known paths to filesystem
access. I don't see much value in retail options that do some of that.
In fact, what they might mostly accomplish is to give people a false
sense of security.

That's a reasonable point. I'll go ahead an explore some options for
something along those lines. A couple of questions immediately come to
mind. For example, should this configuration option just cause these
functions to ERROR, or should it compile them out?

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Nathan Bossart <nathandbossart@gmail.com> writes:

That's a reasonable point. I'll go ahead an explore some options for
something along those lines. A couple of questions immediately come to
mind. For example, should this configuration option just cause these
functions to ERROR, or should it compile them out?

Letting them be present but throw error is likely to be far less
painful than the other way, because then you don't need a separate
set of SQL-visible object definitions. You could, in fact, imagine
jacking up an existing database and driving a set of locked-down
binaries under it --- or vice versa. If there have to be different
versions of the extension SQL files for the two cases then everything
gets way hairier, both for developers and users.

regards, tom lane

On Mon, May 23, 2022 at 02:20:02PM -0400, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

That's a reasonable point. I'll go ahead an explore some options for
something along those lines. A couple of questions immediately come to
mind. For example, should this configuration option just cause these
functions to ERROR, or should it compile them out?

Letting them be present but throw error is likely to be far less
painful than the other way, because then you don't need a separate
set of SQL-visible object definitions. You could, in fact, imagine
jacking up an existing database and driving a set of locked-down
binaries under it --- or vice versa. If there have to be different
versions of the extension SQL files for the two cases then everything
gets way hairier, both for developers and users.

Agreed. I'll do it that way.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Mon, May 23, 2022 at 1:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

There would probably be some interest in a "--disable-disk-access"
configure option that did all of this stuff (and some more things
too), with the aim of locking down *all* known paths to filesystem
access. I don't see much value in retail options that do some of that.
In fact, what they might mostly accomplish is to give people a false
sense of security.

I definitely think there's a need for a user who can manipulate
objects in the database much like a superuser (i.e. access all
objects, grant and revoke all privileges, etc.) but who can't break
out into the OS user account and assume it's privileges. I'm not sure
whether it's best to try to get there by creating a mode where the
superuser's privileges are trimmed back, or to get there by still
having a super-user who is just as super as at present but then also
have the ability to create other users who are not superusers but have
many of the same privileges with respect to in-database objects.

It seems to me that you've got to think not only about vectors for
executing arbitrary C code and/or shell commands, but also the
superuser's power to mess with the catalogs. If you can UPDATE
pg_proc, you can certainly hack the system, I think. But that isn't
really implied by --disable-disk-access, which makes me think that's
not really the right way of thinking about it. In my mind, it's
reasonable as a matter of security policy to decide that you don't
ever want plperlu on your system, only plperl. And it's reasonable to
decide whether or not you also need some kind of restricted super-user
facility. They're just two different issues.

--
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

I definitely think there's a need for a user who can manipulate
objects in the database much like a superuser (i.e. access all
objects, grant and revoke all privileges, etc.) but who can't break
out into the OS user account and assume it's privileges. I'm not sure
whether it's best to try to get there by creating a mode where the
superuser's privileges are trimmed back, or to get there by still
having a super-user who is just as super as at present but then also
have the ability to create other users who are not superusers but have
many of the same privileges with respect to in-database objects.

Maybe I shouldn't be putting words into Nathan's mouth, but I think
what he is after is a mode intended for use by cloud service providers,
who would like to offer locked-down database services where there's
just no way to get to the disk from inside the DB, superuser or no.

What you're talking about is perhaps interesting to a different set of
people, but it doesn't offer any guarantees because it's always possible
that $attacker manages to hack his way into access to a superuser role.

It seems to me that you've got to think not only about vectors for
executing arbitrary C code and/or shell commands, but also the
superuser's power to mess with the catalogs. If you can UPDATE
pg_proc, you can certainly hack the system, I think.

I think if all the functions that would let you get to the disk are
disabled at the C-code level, it doesn't much matter what the catalogs
say about them.

The main flaw I'm aware of in that argument is that it used to be possible
for superusers to create C-language pg_proc entries pointing at random C
entry point symbols, eg open(2) or write(2), and then invoke those
functions from SQL --- maybe with only restricted possibilities for the
arguments, but you just need to find one combination that works.
When we got rid of v0 function call support, that became at least far
more difficult to exploit, but I'm not sure if it's entirely impossible.
A component of this exercise would need to be making sure that that's
bulletproof, ie you can't make a usable pg_proc entry that points at
something that wasn't meant to be a SQL-callable function.

In my mind, it's
reasonable as a matter of security policy to decide that you don't
ever want plperlu on your system, only plperl.

Absolutely, but for that you can just not install plperlu's extension
support files.

If you're concerned about whether that decision is un-hackable, then
you soon realize that you need a bulletproof no-disk-access restriction.

regards, tom lane

On Mon, May 23, 2022 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Maybe I shouldn't be putting words into Nathan's mouth, but I think
what he is after is a mode intended for use by cloud service providers,
who would like to offer locked-down database services where there's
just no way to get to the disk from inside the DB, superuser or no.

The cloud service provider use case is also what I was thinking about.

What you're talking about is perhaps interesting to a different set of
people, but it doesn't offer any guarantees because it's always possible
that $attacker manages to hack his way into access to a superuser role.

I mean, you can hypothesize that any sort of restriction can be
bypassed, regardless of how they're implemented. I don't think this is
a valid way of discriminating among possible solutions.

The main flaw I'm aware of in that argument is that it used to be possible
for superusers to create C-language pg_proc entries pointing at random C
entry point symbols, eg open(2) or write(2), and then invoke those
functions from SQL --- maybe with only restricted possibilities for the
arguments, but you just need to find one combination that works.
When we got rid of v0 function call support, that became at least far
more difficult to exploit, but I'm not sure if it's entirely impossible.
A component of this exercise would need to be making sure that that's
bulletproof, ie you can't make a usable pg_proc entry that points at
something that wasn't meant to be a SQL-callable function.

It's not just a question of whether it was meant to be SQL-callable --
it's also a question of what arguments it was expecting to be called
with. At the very least, you can cause the server to core dump if you
pass something that isn't a valid pointer to a function that is
expecting a pointer, which is something a CSP very likely does not
want a customer to be able to do. I think, however, that there's every
possibility that you can create more havoc than that. You can
basically call a function that's expecting a pointer with a pointer to
anything you can find or guess the memory address of. Maybe that's not
enough control to cause anything worse than a server crash, but I sure
wouldn't bet on it. There's a lot of functions floating around, and if
none of them can be tricked into doing filesystem access today, well
someone might add a new one tomorrow.

--
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

It's not just a question of whether it was meant to be SQL-callable --
it's also a question of what arguments it was expecting to be called
with. At the very least, you can cause the server to core dump if you
pass something that isn't a valid pointer to a function that is
expecting a pointer, which is something a CSP very likely does not
want a customer to be able to do. I think, however, that there's every
possibility that you can create more havoc than that. You can
basically call a function that's expecting a pointer with a pointer to
anything you can find or guess the memory address of. Maybe that's not
enough control to cause anything worse than a server crash, but I sure
wouldn't bet on it. There's a lot of functions floating around, and if
none of them can be tricked into doing filesystem access today, well
someone might add a new one tomorrow.

[ shrug... ] So is your point that we shouldn't bother to do anything?
I don't personally have a problem with leaving things where they stand
in this area. However, if we're going to do something, I think at
minimum it should involve blocking off everything we can identify as
straightforward reproducible methods to get disk access.

regards, tom lane

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Robert Haas <robertmhaas@gmail.com> writes:

It's not just a question of whether it was meant to be SQL-callable --
it's also a question of what arguments it was expecting to be called
with. At the very least, you can cause the server to core dump if you
pass something that isn't a valid pointer to a function that is
expecting a pointer, which is something a CSP very likely does not
want a customer to be able to do. I think, however, that there's every
possibility that you can create more havoc than that. You can
basically call a function that's expecting a pointer with a pointer to
anything you can find or guess the memory address of. Maybe that's not
enough control to cause anything worse than a server crash, but I sure
wouldn't bet on it. There's a lot of functions floating around, and if
none of them can be tricked into doing filesystem access today, well
someone might add a new one tomorrow.

[ shrug... ] So is your point that we shouldn't bother to do anything?
I don't personally have a problem with leaving things where they stand
in this area. However, if we're going to do something, I think at
minimum it should involve blocking off everything we can identify as
straightforward reproducible methods to get disk access.

I have a hard time seeing the value in allowing catalog hacking, even
for a cloud provider, and making sure to cut off all possible ways that
could be abused strikes me as unlikely to be successful.

Instead, I'd argue that we should be continuing to work in the direction
of splitting up what can only be done by a superuser today using
predefined roles and other methods along those lines. How that lines up
with this latest ask around untrusted languages is something I'm not
exactly sure about, but a magic configure option that is
"--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
like it's going in the right direction (and, no, not every cloud
provider is going to want the exact same thing when it comes to whatever
this option is that we're talking about, so we'd end up having to have
configure options for each if we start going down this road...).

I agree with the general idea of "has all of today's superuser rights
except the ability to hack catalogs or do disk access" being one
use-case we should be thinking about, along with "also can't do network
access" and "allowed to do network or disk access but can't directly
hack up the catalog", but I don't see us growing configure options for
all these things and would much rather we have a way to let folks
configure their systems along these different lines, ideally without
having to make that decision at build time.

Thanks,

Stephen

On Mon, May 23, 2022 at 07:09:03PM -0400, Stephen Frost wrote:

Instead, I'd argue that we should be continuing to work in the direction
of splitting up what can only be done by a superuser today using
predefined roles and other methods along those lines. How that lines up
with this latest ask around untrusted languages is something I'm not
exactly sure about, but a magic configure option that is
"--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
like it's going in the right direction (and, no, not every cloud
provider is going to want the exact same thing when it comes to whatever
this option is that we're talking about, so we'd end up having to have
configure options for each if we start going down this road...).

I guess I'd like to do both. I agree with continuing the work with
predefined roles, etc., but I also think there is value in being able to
compile out things that allow arbitrary disk/network access. My intent
with this thread is the latter, and I'm trying to tackle this in a way that
is generically useful even beyond the cloud provider use case.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On 5/23/22 8:04 PM, Nathan Bossart wrote:

On Mon, May 23, 2022 at 07:09:03PM -0400, Stephen Frost wrote:

Instead, I'd argue that we should be continuing to work in the direction
of splitting up what can only be done by a superuser today using
predefined roles and other methods along those lines. How that lines up
with this latest ask around untrusted languages is something I'm not
exactly sure about, but a magic configure option that is
"--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
like it's going in the right direction (and, no, not every cloud
provider is going to want the exact same thing when it comes to whatever
this option is that we're talking about, so we'd end up having to have
configure options for each if we start going down this road...).

I guess I'd like to do both. I agree with continuing the work with
predefined roles, etc., but I also think there is value in being able to
compile out things that allow arbitrary disk/network access. My intent
with this thread is the latter, and I'm trying to tackle this in a way that
is generically useful even beyond the cloud provider use case.

(+1 on continuing to split up superuser into other predefined roles and
other privs)

For other use cases, I suggest considering PostgreSQL deployments in
environments that run on restricted filesystems, e.g. containers. When
configured properly, a containerized filesystem will disallow writes
outside of the data directory. However, a) they typically only restrict
writes (which is often good enough) and b) this model holds so long as
there are no exploits in the container itself.

The latter may not be our problem, but we can provide an additional risk
mitigation for folks who deploy PostgreSQL in containers or other
restricted environments the option to compile out features that do allow
arbitrary disk access.

I agree with a bunch of the upthread sentiment, but I would ask if the
current proposal provides acceptable risk mitigation for PostgreSQL
deployments who want to restrict users having access to the filesystem?

Jonathan

On Mon, May 23, 2022 at 6:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

[ shrug... ] So is your point that we shouldn't bother to do anything?
I don't personally have a problem with leaving things where they stand
in this area. However, if we're going to do something, I think at
minimum it should involve blocking off everything we can identify as
straightforward reproducible methods to get disk access.

No, my point is that one size doesn't fit all. Bundling everything
together that could result in a disk access is going to suck too many
marginally-related into the same bucket. It's much better to have
individual switches controlling individual behaviors, so that people
can opt into or out of the behavior that they want.

I would argue that Stephen's proposal (that is, using predefined roles
more) and Nathan's proposal (that is, making it possible to build only
the trusted version of some PL) are tackling this problem are far
superior to your idea (that is, a flag to disable all disk access)
precisely because they are more granular. Your idea appears to
presuppose that there is exactly one thing in this area that anybody
wants and that we know what that thing is. I think people want a bunch
of slightly different things and that we're probably unaware of many
of them. Letting them pick which behaviors they want seems to me to
make a lot of sense.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote:

On Mon, May 23, 2022 at 6:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

[ shrug... ] So is your point that we shouldn't bother to do anything?
I don't personally have a problem with leaving things where they stand
in this area. However, if we're going to do something, I think at
minimum it should involve blocking off everything we can identify as
straightforward reproducible methods to get disk access.

No, my point is that one size doesn't fit all. Bundling everything
together that could result in a disk access is going to suck too many
marginally-related into the same bucket. It's much better to have
individual switches controlling individual behaviors, so that people
can opt into or out of the behavior that they want.

I would argue that Stephen's proposal (that is, using predefined roles
more) and Nathan's proposal (that is, making it possible to build only
the trusted version of some PL) are tackling this problem are far
superior to your idea (that is, a flag to disable all disk access)
precisely because they are more granular. Your idea appears to
presuppose that there is exactly one thing in this area that anybody
wants and that we know what that thing is. I think people want a bunch
of slightly different things and that we're probably unaware of many
of them. Letting them pick which behaviors they want seems to me to
make a lot of sense.

Can we do both? That is, can we add retail options for untrusted
languages, generic file access functions, etc., and then also introduce a
--disable-disk-access configuration option? The latter might even just be
a combination of retail options. This would allow for more granular
configurations, but it also could help address Tom's concerns.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Nathan Bossart <nathandbossart@gmail.com> writes:

On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote:

No, my point is that one size doesn't fit all. Bundling everything
together that could result in a disk access is going to suck too many
marginally-related into the same bucket. It's much better to have
individual switches controlling individual behaviors, so that people
can opt into or out of the behavior that they want.

Can we do both? That is, can we add retail options for untrusted
languages, generic file access functions, etc., and then also introduce a
--disable-disk-access configuration option? The latter might even just be
a combination of retail options. This would allow for more granular
configurations, but it also could help address Tom's concerns.

Don't see why not.

I'm a bit skeptical of Robert's position, mainly because I don't think
he's offered any credible threat model that would justify disabling
individual features of this sort but not all of them. However, if what
it takes to have consensus is some individual knobs in addition to an
"easy button", let's do it that way.

regards, tom lane

On Tue, May 24, 2022 at 1:28 PM Nathan Bossart <nathandbossart@gmail.com> wrote:

Can we do both? That is, can we add retail options for untrusted
languages, generic file access functions, etc., and then also introduce a
--disable-disk-access configuration option? The latter might even just be
a combination of retail options. This would allow for more granular
configurations, but it also could help address Tom's concerns.

Oh, sure. We're in charge around here. We can do whatever we want! The
only trick is agreeing with each other to a sufficient degree to get
something done ... and of course the small matter of writing the code.

I guess one question is at what level we want to disable these various
things. Your original proposal seemed reasonable to me because I feel
like users who are compiling PostgreSQL ought to have control over
which things they compile. If you can turn plperl and plperlu off
together, and you can, then why shouldn't you be able to turn them on
and off separately? I can't think of a good reason why we shouldn't
make that possible if people want it, and evidently at least one
person does: you. I'm even willing to assume that you represent the
interests of some larger group of people. :-)

But it's not evident to me that it's useful to disable everything
specifically at compile time. I have long thought that it's pretty
bizarre that we permit DML on system catalogs even with
allow_system_table_mods=off, and if I were going to provide a way to
lock that down, I would think of doing it via a new GUC, or a
modification to the existing GUC, or something like that, rather than
a compile-time option -- because we might easily discover a problem in
a future release that requires catalog DML to fix, and you wouldn't
want to have to replace the binaries or even bounce the server to do
that.

And similarly, is it really want we want here to categorically disable
all functions that permit file access for all users under all
circumstances? Or do we maybe want that to be something that can be
reconfigured at runtime? Or even just make it a privilege extended to
some users but not others? What about COPY TO/FROM PROGRAM?

Anyway, I'm not desperately opposed to the idea of having a PostgreSQL
mode that locks a whole lotta crap down at configure time, but I bet
it's going to be (1) hard to get agreement that all of the relevant
stuff is actually worth including and (2) kinda inconvenient not to be
able to change any of that behavior without replacing the binaries. I
do agree that there are SOME things where people are going to
explicitly want that stuff to be unchangeable without replacing the
binaries, and that's fine. I'm just not sure that's what people are
going to want in all cases.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Tue, May 24, 2022 at 02:10:19PM -0400, Robert Haas wrote:

I guess one question is at what level we want to disable these various
things. Your original proposal seemed reasonable to me because I feel
like users who are compiling PostgreSQL ought to have control over
which things they compile. If you can turn plperl and plperlu off
together, and you can, then why shouldn't you be able to turn them on
and off separately? I can't think of a good reason why we shouldn't
make that possible if people want it, and evidently at least one
person does: you. I'm even willing to assume that you represent the
interests of some larger group of people. :-)

:)

FWIW this was my original thinking. I can choose to build/install
extensions separately, but when it comes to PL/Tcl and PL/Perl, you've
got to build the trusted and untrusted stuff at the same time, and the
untrusted symbols remain even if you remove the control file and
installation scripts. Of course, this isn't a complete solution for
removing the ability to do any sort of random file system access, though.

But it's not evident to me that it's useful to disable everything
specifically at compile time. I have long thought that it's pretty
bizarre that we permit DML on system catalogs even with
allow_system_table_mods=off, and if I were going to provide a way to
lock that down, I would think of doing it via a new GUC, or a
modification to the existing GUC, or something like that, rather than
a compile-time option -- because we might easily discover a problem in
a future release that requires catalog DML to fix, and you wouldn't
want to have to replace the binaries or even bounce the server to do
that.

Yeah, for certain things, a GUC probably makes more sense.

And similarly, is it really want we want here to categorically disable
all functions that permit file access for all users under all
circumstances? Or do we maybe want that to be something that can be
reconfigured at runtime? Or even just make it a privilege extended to
some users but not others? What about COPY TO/FROM PROGRAM?

I guess I'd ask again whether we can do both... We've got predefined roles
like pg_execute_server_program that allow access to COPY TO/FROM PROGRAM,
but I have no way to categorically disable that ѕort of thing if I wanted
to really lock things down, even for superusers. I'm not suggesting that
every predefined role needs a corresponding configure option, but basic
things like arbitrary disk/network/program access seem like reasonable
proposals.

I have about 50% of a generic --disable-disk-access patch coded up which
I'll share soon to help inform the discussion.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Tue, May 24, 2022 at 02:10:19PM -0400, Robert Haas wrote:

I guess one question is at what level we want to disable these various
things. Your original proposal seemed reasonable to me because I feel
like users who are compiling PostgreSQL ought to have control over
which things they compile. If you can turn plperl and plperlu off
together, and you can, then why shouldn't you be able to turn them on
and off separately? I can't think of a good reason why we shouldn't
make that possible if people want it, and evidently at least one
person does: you. I'm even willing to assume that you represent the
interests of some larger group of people. :-)

I always thought if pg_proc is able to call an arbitrary function in an
arbitrary library, it could access to the file system, and if that is
true, locking the super-user from file system access seems impossible
and unwise to try because it would give a false sense of security.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Indecision is a decision. Inaction is an action. Mark Batterson