Feedback-ID: i19364b5b:Fastmail
From: "Jonathan Gonzalez V." <jonathan@abdiel.eu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Introduce psystem() to replace system()
In-Reply-To: <2314092.1786402806@sss.pgh.pa.us>
References: <87zeyt93ns.fsf@abdiel.eu> <2314092.1786402806@sss.pgh.pa.us>
Date: Wed, 19 Aug 2026 13:53:21 +0200
Message-ID: <87wltmz5qm.fsf@abdiel.eu>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
 <https://www.postgresql.org/message-id/87wltmz5qm.fsf%40abdiel.eu>
Precedence: bulk


Hello!

Tom Lane <tgl@sss.pgh.pa.us> writes:
> "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.

I found a lot of discussions in the past, that's why I thought the idea
will be of interest. The stdio-redirection, it's for now, just something
for send stuff to DEVNULL, probably it can evolve in future patches, but
for now, I think that for the silent stuff it's enough, because the
redirection stuff will open the door to manage some piping and the idea
it's to remove those kind of needs too.

In terms of security, there is an improvement, but for performance, I wasn't
able to establish a base line or even what to measure, but I can imagine
that people here may have more ideas about what and how to measure it.

> 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.

I'm pretty sure it will not, but I open the door to think about it and
keep I'm trying to keep in mind those situations when thinking about the
design of the patches.

> 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.

Well, that function it's designed in case we should keep compatibility
with system(), I'm not happy with that idea but it may be required, but
if we can avoid having that from the beginning I'm more than happy with
this.

With all that said, I'll start putting some documentation and clarify
the concepts for this and have a better v2 version.

Regards!
--
Jonathan Gonzalez V.
EDB
https://www.enterprisedb.com