On Thu, Mar 14, 2024 at 3:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> With the possible exception of #1, every one of these is easily
> defeatable by an uncooperative superuser. I'm not excited about
> adding a "security" feature with such obvious holes in it.
> We reverted MAINTAIN last year for much less obvious holes;
> how is it that we're going to look the other way on this one?
We're going to document that it's not a security feature along the
lines of what Magnus suggested in
http://postgr.es/m/CABUevEx9m=CV8=WpXVW+rtVVs858kDJ6YpRkExV7n+F6MK05CQ@mail.gmail.com
And then maybe someday we'll do this:
> Really we'd need to do something about removing superusers'
> access to the filesystem in order to build something with
> fewer holes. I'm not against inventing such a feature,
> but it'd take a fair amount of work and likely would end
> in a noticeably less usable system (no plpython for example).
Yep. It would be useful if you replied to the portion of
http://postgr.es/m/CA+TgmoasUgkZ27x0XZH4EdmQ_b6JbRT6cSUxf+pHdgj-ESk_zA@mail.gmail.com
where I enumerate the methods that I know about for the superuser to
get filesystem access. I don't think it's going to be practical to
block all of those methods in a single commit, and I'm not entirely
convinced that we can ever close all the holes without compromising
the superuser's ability to do necessary system administration tasks,
but maybe it's possible, and documenting the list of such methods
would make it a lot easier for users to understand the risks and
hackers to pick problems to try to tackle.
--
Robert Haas
EDB: http://www.enterprisedb.com