On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost <sfrost@snowman.net> wrote:
> While we have been working to reduce the number of superuser() checks in
> the backend in favor of having the ability to GRANT explicit rights, one
> of the guideing principles has always been that capabilities which can
> be used to gain superuser rights with little effort should remain
> restricted to the superuser, which is why the lo_import/lo_export hadn't
> been under consideration for superuser-check removal in the analysis I
> provided previously.
I disagree that that is, or should be, a guiding principle. I'm not
sure that anyone other than you and your fellow employees at Crunchy
has ever agreed that this is some kind of principle. You make it
sound like there's a consensus about this, but I think there isn't.
I think our guiding principle should be to get rid of ALL of the
hard-coded superuser checks and let people GRANT what they want. If
they grant a permission that results in somebody escalating to
superuser, they get to keep both pieces. Such risks might be worth
documenting, but we shouldn't obstruct people from doing it.
In the same way, Linux will not prevent you from making a binary
setuid regardless of what the binary does. If you make a binary
setuid root that lets someone hack root, that's your fault, not the
operating system.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
