On Tue Sep 16 08:40 AM, Bill Moran wrote: > In response to Tom Lane <tgl@xxxxxxxxxxxxx>: > >> Bill Moran <wmoran@xxxxxxxxxxxxxxxxxxxxxxx> 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.
