On Tue, May 24, 2022 at 1:28 PM Nathan Bossart <nathandboss...@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
