Re: allow building trusted languages without the untrusted versions
От | Stephen Frost |
---|---|
Тема | Re: allow building trusted languages without the untrusted versions |
Дата | |
Msg-id | 20220525174940.GQ9030@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: allow building trusted languages without the untrusted versions (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: allow building trusted languages without the untrusted versions
|
Список | pgsql-hackers |
Greetings, * Nathan Bossart (nathandbossart@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
Вложения
В списке pgsql-hackers по дате отправления: