Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)
От | Jonathan Bond-Caron |
---|---|
Тема | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) |
Дата | |
Msg-id | 003201c91801$95eeaa10$c1cbfe30$@com обсуждение исходный текст |
Ответ на | Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) (Bill Moran <wmoran@collaborativefusion.com>) |
Ответы |
Re: Obfuscated stored procedures (was Re: Oracle and
Postgresql)
Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: