On Thu, Mar 14, 2024 at 3:13 PM Tom Lane <t...@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+f6mk0...@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...@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