On Tue, May 24, 2022 at 09:19:40PM -0400, Tom Lane wrote: > Bruce Momjian <br...@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.
Okay, good to know. > 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. Yes, I think if we can say we are safe in standard superuser-changeable things like modifying the system tables, we might have a chance. Are settings like archive_command safe? -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
