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.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmoran@collaborativefusion.com
Phone: 412-422-3463x4023
