On Tue Sep 16 08:40 AM, Bill Moran wrote:
> In response to Tom Lane <tgl@sss.pgh.pa.us>:
>
>> Bill Moran <wmoran@collaborativefusion.com> writes:
>>> What I'm _asking_ is why would extending SECURITY DEFINER to include
>>> preventing unauthorized users from viewing code _not_ be a valid
>>> method of securing the code.
>>
>> Because it's so full of obvious loopholes. Yes, it might slow down
>> someone who didn't have superuser access to the database or root
>> access to the machine it's on; but that doesn't count as secure
>> really. The problem is that the people who ask for this type of
>> feature are usually imagining that they can put their code on
>> customer-controlled machines and it will be safe from the customer's
>> eyes. Well, it isn't, and I don't think Postgres should encourage
> them to think it is.
>
> Shame that. I can imagine it being a useful feature in certain
> situations (such as a hosted environment), although I understand the
> concern.
>
> Code obfuscation is the norm, though. The world at large still seems
> to believe that compiling code make it secret, despite the fact that
> crooks have demonstrated again and again that they're more than
> willing to read through opcodes, and the fact that there are
> decompilers available for just about every major compiled format.
>
I agree here. I hope there's a consensus that it does offer some level of
protection.
After some research, I found this article that I believe will make a
stronger use case:
http://www.iosn.net/network/news/Managing%20the%20insider%20threat%20through
%20code%20obfuscation
Whether or not it belongs in PG I don't really have an opinion.
