Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > It's not just a question of whether it was meant to be SQL-callable --
> > it's also a question of what arguments it was expecting to be called
> > with. At the very least, you can cause the server to core dump if you
> > pass something that isn't a valid pointer to a function that is
> > expecting a pointer, which is something a CSP very likely does not
> > want a customer to be able to do. I think, however, that there's every
> > possibility that you can create more havoc than that. You can
> > basically call a function that's expecting a pointer with a pointer to
> > anything you can find or guess the memory address of. Maybe that's not
> > enough control to cause anything worse than a server crash, but I sure
> > wouldn't bet on it. There's a lot of functions floating around, and if
> > none of them can be tricked into doing filesystem access today, well
> > someone might add a new one tomorrow.
>
> [ shrug... ] So is your point that we shouldn't bother to do anything?
> I don't personally have a problem with leaving things where they stand
> in this area. However, if we're going to do something, I think at
> minimum it should involve blocking off everything we can identify as
> straightforward reproducible methods to get disk access.
I have a hard time seeing the value in allowing catalog hacking, even
for a cloud provider, and making sure to cut off all possible ways that
could be abused strikes me as unlikely to be successful.
Instead, I'd argue that we should be continuing to work in the direction
of splitting up what can only be done by a superuser today using
predefined roles and other methods along those lines. How that lines up
with this latest ask around untrusted languages is something I'm not
exactly sure about, but a magic configure option that is
"--don't-allow-what-AWS-doesn't-want-to-allow" certainly doesn't seem
like it's going in the right direction (and, no, not every cloud
provider is going to want the exact same thing when it comes to whatever
this option is that we're talking about, so we'd end up having to have
configure options for each if we start going down this road...).
I agree with the general idea of "has all of today's superuser rights
except the ability to hack catalogs or do disk access" being one
use-case we should be thinking about, along with "also can't do network
access" and "allowed to do network or disk access but can't directly
hack up the catalog", but I don't see us growing configure options for
all these things and would much rather we have a way to let folks
configure their systems along these different lines, ideally without
having to make that decision at build time.
Thanks,
Stephen