Re: Facility for detecting insecure object naming

Mark Dilger <hornschnorter(at)gmail(dot)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.

The point of the function trust proposal was to provide some degree of
security even in an environment where there are untrusted schemas in your
search path. However, the other approach we could take is to deprecate
doing that: tell people to stop putting executable objects in "public",
or maybe even deprecate "public" altogether, so that PG search paths are
treated more like Unix PATH settings. You don't put /tmp in your PATH.

The problem with that, of course, is the extent to which it'd break
existing applications --- but having to run around and decorate your
functions with lexical search path settings isn't exactly a free lunch
either.

regards, tom lane