From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan Gonzalez V." <jonathan@abdiel.eu>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Introduce psystem() to replace system()
In-reply-to: <87zeyt93ns.fsf@abdiel.eu>
References: <87zeyt93ns.fsf@abdiel.eu>
Comments: In-reply-to "Jonathan Gonzalez V." <jonathan@abdiel.eu>
	message dated "Mon, 10 Aug 2026 21:27:51 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2314091.1786402806.1@sss.pgh.pa.us>
Date: Mon, 10 Aug 2026 19:00:06 -0400
Message-ID: <2314092.1786402806@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2314092.1786402806%40sss.pgh.pa.us>
Precedence: bulk

"Jonathan Gonzalez V." <jonathan@abdiel.eu> writes:
> For some time I've been wondering why PostgreSQL needs system() calls,
> which use a shell that can lead to many problems, and also why it
> requires a shell to run a command.

There's a lot to be said for not going through system() if we don't
have to, and I think you are right that there are many places where
we don't have to, if we're willing to write our own stdio-redirection
code (but that might be a bigger can of worms than it seems).  That'd
improve security and also performance, though I'm not very sure how
big the latter win would be.

However, I think your apparent ambition to have *zero* use of system()
is a bridge too far.  In particular:

> There's an important topic related to using shell versus not a shell. In
> some places like `archive_command` people may use `&&`, but this idea
> aims to avoid this kind of behavior since it's not secure.

I think breaking the existing definition of archive_command and
similar GUCs is a nonstarter.  You're going to make many users
unhappy and only a tiny minority happier.

There might be some way to compromise, along the lines of "if the
string contains no shell metacharacters then parse it ourselves and
use execv(), else use system()".  The devil's in the details there;
but if it could work then it'd satisfy people who'd like to not
have a shell available and are willing to deal with the ensuing
restrictions.  But if you think that description covers all or even
most of our users, I'm here to tell you you're wrong.

As for details ... doesn't this pcommand_count_args thing break
instantly on cases like pathnames containing spaces?  I think
you need a much clearer concept (and, um, some documentation)
about the semantics of these functions.  I don't think we're
really going to move the goalposts far unless we can get away
from assumptions like that.

			regards, tom lane