Re: Facility for detecting insecure object naming

> On Aug 15, 2018, at 9:02 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>> I think you are interpreting the problem too broadly. This is basically
>> just a privilege escalation attack vector.
>
> Hmm. Well, I think you're interpreting the problem too narrowly. :-)
>
> In my view, the problem isn't just that there is a risk of privilege
> escalation; in fact, for many users, that's not a serious problem at
> all because the database has only one user anyway. I think that the
> core problem is that you can easily write code that looks like it will
> work just fine and then have it not work at all. For example,
> somebody:
>
> - creates an SQL or PL/plgsql function
> - uses it to define a functional index
> - runs REINDEX with a different search path
> - gets an error because there's some unqualified or ambiguous
> reference inside the SQL function
>
> There might be a security risk here if the REINDEX is run by a
> different user with elevated privileges, because then maybe one of the
> references inside the SQL or PL/plgsql function could be captured by a
> new and malicious object injected into the alternative search path,
> but that's not really the point. The point is that you might
> reasonably want this to WORK AS INTENDED, not just fail to be
> insecure. If your house gets hit by lightning and, as a result, your
> alarm system goes offline, you do have a potential security problem,
> but also, every appliance in your house is probably fried, and your
> house may be on fire. Focusing on the security system specifically is
> likely the wrong approach.

I'm like some aspects of what you are proposing.

The ability to define local variables in perl is not a bug. I
frequently use

undef(local $/)

and I wouldn't want that taken away by some perl developer who decides
that the next version of perl won't have local variables. (Maybe this
went away with perl 6 -- I haven't checked.)

You want to fix the problem by having an option to lexically scope
variables. That's fine as far as it goes. But if the option to not
use lexically scoped variables, and to use dynamically scoped variables
remains, with the function author choosing between the two modes, then
you're basically writing off the users of dynamically scoped variables
by saying, in effect, "we're never going to fix the security problem
you have, and if you want to be secure, stop using that deprecated
dynamically scoped variable feature, move into the 21st century, and
use lexically scoped variables like Robert does".

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.

mark