From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Robert Haas <robertmhaas@gmail.com>,
        Nathan Bossart <nathandbossart@gmail.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow building trusted languages without the untrusted versions
In-reply-to: <Yo1wKuifvjUfv4hb@momjian.us>
References: <571753.1653092411@sss.pgh.pa.us>
 <20220523165403.GC938919@nathanxps13> <1290329.1653326228@sss.pgh.pa.us>
 <CA+TgmoY-Xy_ObfYVUTSamD8BmW8npaktbr65JtnkW-c1VQobVA@mail.gmail.com>
 <1333860.1653338790@sss.pgh.pa.us>
 <CA+TgmoYZKLxftaZZvj4_-zHQ27CBeUs+KvggyU3qS79-7aQEPA@mail.gmail.com>
 <1354561.1653345768@sss.pgh.pa.us>
 <CA+TgmoZ_c0j4ut87_QCFm697Qq5Z_u66VZt2PYenfZVjUT1qRA@mail.gmail.com>
 <20220524172851.GA1191690@nathanxps13>
 <CA+TgmobOQiDXpYq6TgaCzH3p5c0Fko-wXqCjgd5YsR6RsX31vA@mail.gmail.com>
 <Yo1wKuifvjUfv4hb@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Tue, 24 May 2022 19:54:18 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1772515.1653441580.1@sss.pgh.pa.us>
Date: Tue, 24 May 2022 21:19:40 -0400
Message-ID: <1772516.1653441580@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1772516.1653441580%40sss.pgh.pa.us>
Precedence: bulk

Bruce Momjian <bruce@momjian.us> writes:
> 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.

That was the situation when we had v0 function call semantics.  ISTM
we are at least a lot closer now to being able to say it's locked down:
"internal" functions can only reach things that are in the fmgrtab
table, and "C" functions can only reach things that have associated
PG_FUNCTION_INFO_V1 symbols.  Plus we won't load shared libraries
that don't have PG_MODULE_MAGIC blocks.  Maybe there's still a way
around all that, but it's sure a lot less obvious than it once was,
and there are probably things we could do to make it even harder.

I think would-be hackers are now reduced to doing what Robert
suggested, which is trying to find a way to subvert a validly
SQL-callable function by passing it bogus arguments.  Maybe there's
a way to gain filesystem access by doing that, but it's not going
to be easy if the function is not one that intended to allow such
operations.

			regards, tom lane