Re: Facility for detecting insecure object naming - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Facility for detecting insecure object naming |
Date | |
Msg-id | CA+Tgmoa5GHrv5dbwmgLRE4SO3rf_WG7-Tf7WWX0G87e0rcwk7A@mail.gmail.com Whole thread Raw |
In response to | Re: Facility for detecting insecure object naming (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Thu, Aug 16, 2018 at 12:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Mark Dilger <hornschnorter@gmail.com> writes: >> Go ahead and define some new lexical scope mechanism. I'm probably >> going to move into the 21st century with you and use it. (I mostly >> use "my", not "local", when I write perl code.) But let's treat that as >> a new feature independent of fixing the security problems with dynamically >> scoped variables and privilege escalation attacks. > > To my mind, the really fundamental problem here is that our default/ > traditional search_path includes publicly writable schemas. I don't > especially care whether you establish your search_path setting > dynamically, or lexically, or through magic hocus pocus: if it includes a > schema that a hostile user can create objects in, you'll get pwned sooner > not later. So it doesn't seem to me that Robert's proposal is really > doing much to move the goalposts. He's presuming that the main problem > is that user A and user B have different ideas about which schemas are > trusted ... but I think that that is, at most, a minority use-case. > I suspect that a system-wide definition of which schemas are trusted > would serve many installations just fine. I agree that if this is the sort of thing you are worried about, then function trust is a reasonable step in a good direction. It is definitely the case that letting hostile users put stuff into your search path provides a large number of ways for them to potentially pwn you. I do wonder whether, instead of de-trusting those users, you ought not to instead deny them the ability to create objects in your search_path, either by changing their privileges or by changing your own search path. But if you can't do that for some reason, de-trusting executable objects that they create in that search_path is a good thing to be able to do. But that's not really where I think the biggest problems are, even though I agree that those are problems. In my view, the biggest problem is that sometimes you may need to write code that works with any search_path setting. pg_dump is a good example. It's got to iterate through all of the schemas in the system and dump them all. Extensions are another example. If you install the earthdistance extension, it's supposed to work no matter how search_path is set when the functions it contains get called. Functions used in defining expression indexes are another example; you want them to work the same way no matter what the prevailing search_path happens to be when tuples are inserted or the table gets reindexed. As long as it's straightforward to swap out the search path under which the function was intended to execute for some other one, stuff is going to break. Again, this is not an argument against function trust, which I actually think is a pretty good proposal. It just doesn't address the thing I personally consider to be the biggest problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: