Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > I guess I'd ask again whether we can do both... We've got predefined roles > like pg_execute_server_program that allow access to COPY TO/FROM PROGRAM, > but I have no way to categorically disable that Ń•ort of thing if I wanted > to really lock things down, even for superusers. I'm not suggesting that > every predefined role needs a corresponding configure option, but basic > things like arbitrary disk/network/program access seem like reasonable > proposals.
Locking things down "even for superuser" is something we've very explicitly said we're not going to try and do. Even with v1 functions, the ability to hack around with pg_proc strikes me as almost certainly going to provide a way for someone to gain enough control of execution to be able to 'break out', not to mention obvious other things like ALTER SYSTEM to change archive_command to run whatever shell commands an attacker with superuser wants to.. > I have about 50% of a generic --disable-disk-access patch coded up which > I'll share soon to help inform the discussion. Do you disable the ability of superusers to use ALTER SYSTEM with this? I really don't think this is going to be anywhere near as straight-forward as it might appear to be to prevent a superuser from being able to break out of PG. Instead, we should be moving in the direction of making it so that there doesn't need to be a superuser that's ever logged into except under serious emergency situations where the system is built to require multi-person access to do so. Thanks, Stephen
signature.asc
Description: PGP signature
