Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas <robertmh...@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
signature.asc
Description: PGP signature
