On Mon, May 23, 2022 at 1:17 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > There would probably be some interest in a "--disable-disk-access" > configure option that did all of this stuff (and some more things > too), with the aim of locking down *all* known paths to filesystem > access. I don't see much value in retail options that do some of that. > In fact, what they might mostly accomplish is to give people a false > sense of security.
I definitely think there's a need for a user who can manipulate objects in the database much like a superuser (i.e. access all objects, grant and revoke all privileges, etc.) but who can't break out into the OS user account and assume it's privileges. I'm not sure whether it's best to try to get there by creating a mode where the superuser's privileges are trimmed back, or to get there by still having a super-user who is just as super as at present but then also have the ability to create other users who are not superusers but have many of the same privileges with respect to in-database objects. It seems to me that you've got to think not only about vectors for executing arbitrary C code and/or shell commands, but also the superuser's power to mess with the catalogs. If you can UPDATE pg_proc, you can certainly hack the system, I think. But that isn't really implied by --disable-disk-access, which makes me think that's not really the right way of thinking about it. In my mind, it's reasonable as a matter of security policy to decide that you don't ever want plperlu on your system, only plperl. And it's reasonable to decide whether or not you also need some kind of restricted super-user facility. They're just two different issues. -- Robert Haas EDB: http://www.enterprisedb.com
