Thread: Hide source code
Hi,
I'm looking for a way to hide the souce code of my system (functions).
In Oracle, I can wrap it. Is there something that I can use to hide and/or wrap my source code?
Att.
Márcio A. Sepp
ZYON TECNOLOGIA LTDA
Márcio A. Sepp
ZYON TECNOLOGIA LTDA
On Sun, Jul 10, 2005 at 04:26:26AM -0300, Márcio A. Sepp wrote: > I'm looking for a way to hide the souce code of my system (functions). > > In Oracle, I can wrap it. Is there something that I can use to hide > and/or wrap my source code? Write the functions in C and distribute only a binary? Maybe in Java, and use something like gcj; or Mono/.Net equivalents? Write an Intercal language handler? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) "You knock on that door or the sun will be shining on places inside you that the sun doesn't usually shine" (en Death: "The High Cost of Living")
Márcio A. Sepp wrote:
>
> Hi,
>
>
> I'm looking for a way to hide the souce code of my system (functions).
>
> In Oracle, I can wrap it. Is there something that I can use to hide
> and/or wrap my source code?
>
>
> Att.
>
> Márcio A. Sepp
> ZYON TECNOLOGIA LTDA
Currently there is no way to do that.
Best regards,
Hans
On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote: > Hi, > > I'm looking for a way to hide the souce code of my system > (functions). > > In Oracle, I can wrap it. Is there something that I can use to hide > and/or wrap my source code? If you have code that you don't want people to take, use the copyright and license system, which works, not the obfuscation system, which is amazingly fragile. And besides, what's so embarrassing about this code that you don't want people to see it? Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
> On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote: > > Hi, > > > > I'm looking for a way to hide the souce code of my system > > (functions). > > > > In Oracle, I can wrap it. Is there something that I can use to hide > > and/or wrap my source code? > > If you have code that you don't want people to take, use the copyright > and license system, which works, not the obfuscation system, which is > amazingly fragile. And besides, what's so embarrassing about this > code that you don't want people to see it? This was discusses extensively in the archives about a month ago. Actually it is possible to 'hide' the source code so that a database user can't view it (or anything else) in psql by manipulating system schema permissions. Regardless of your philosophical standpoint, many larger organizations will feel uncomfortable with having unprivileged users having access to all the database procedure source code. Merlin
On Mon, Jul 11, 2005 at 07:59:44AM -0400, Merlin Moncure wrote: > > On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote: > > > Hi, > > > > > > I'm looking for a way to hide the souce code of my system > > > (functions). > > > > > > In Oracle, I can wrap it. Is there something that I can use to > > > hide and/or wrap my source code? > > > > If you have code that you don't want people to take, use the > > copyright and license system, which works, not the obfuscation > > system, which is amazingly fragile. And besides, what's so > > embarrassing about this code that you don't want people to see it? > > This was discusses extensively in the archives about a month ago. > Actually it is possible to 'hide' the source code so that a database > user can't view it (or anything else) in psql by manipulating system > schema permissions. Interesting. Again, this is pretty fragile with respect to, for example, pg_dump(all). > Regardless of your philosophical standpoint, many larger > organizations will feel uncomfortable with having unprivileged users > having access to all the database procedure source code. That some "larger organizations" choose to use the known-unsafe method of security by obscurity is not a reason for anybody here to expend any effort helping them persist in this illusion: quite the opposite, in fact. "Larger organizations" are likely to have security needs which they actually need to address, not to pretend they've addressed while actually making things easy for attackers. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
David, > That some "larger organizations" choose to use the known-unsafe method > of security by obscurity is not a reason for anybody here to expend > any effort helping them persist in this illusion: quite the opposite, > in fact. "Larger organizations" are likely to have security needs > which they actually need to address, not to pretend they've addressed > while actually making things easy for attackers. Hmmm, I agree with Merlin, I think. It would be nice if users who didn't have permission to EXECUTE functions couldn't view their code, either. This would probably carry a performance penalty, though. Users with EXECUTE permission not being able to see code just isn't practical; we support too many interpreted languages. If this is a concern, use C functions and compile binaries. That's secure. -- Josh Berkus Aglio Database Solutions San Francisco
On Mon, Jul 11, 2005 at 09:27:19AM -0700, Josh Berkus wrote: > David, > > > That some "larger organizations" choose to use the known-unsafe > > method of security by obscurity is not a reason for anybody here > > to expend any effort helping them persist in this illusion: quite > > the opposite, in fact. "Larger organizations" are likely to have > > security needs which they actually need to address, not to pretend > > they've addressed while actually making things easy for attackers. > > Hmmm, I agree with Merlin, I think. It would be nice if users who > didn't have permission to EXECUTE functions couldn't view their > code, either. Why? > This would probably carry a performance penalty, though. > Users with EXECUTE permission not being able to see code just isn't > practical; we support too many interpreted languages. If this is a > concern, use C functions and compile binaries. That's secure. With all due respect, it's not even *close* to secure. There are plenty of tools out there that allow a person to de-compile a shared library. A lot of people have learned the hard way over the decades that any security measure that depends on the attacker's not knowing the implementation details is fragile, often disastrously so, e.g. the Enigma machine & friends. There is no good reason for us to help perpetuate the myth of security by obscurity, and plenty of good reasons for us *not* to do so. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
> On Mon, Jul 11, 2005 at 07:59:44AM -0400, Merlin Moncure wrote: > Interesting. Again, this is pretty fragile with respect to, for > example, pg_dump(all). No, it isn't. If you revoke permission on pg_proc, /df in psql will fail, as will pg_dump. Try it (you have to revoke all on pg_proc form public). See the log below: C:\svn\rcsi\Etc>pg_dump -U test xxx pg_dump: SQL command failed pg_dump: Error message from server: ERROR: permission denied for relation pg_proc pg_dump: The command was: SELECT tableoid, oid, proname, prolang, pronargs, proargtypes, prorettypproacl, pronamespace, (select usename from pg_user where proowner = usesysid) as usename FROM pg_ oc WHERE NOT proisagg AND pronamespace != (select oid from pg_namespace where nspname = 'pg_catalo ) > > Regardless of your philosophical standpoint, many larger > > organizations will feel uncomfortable with having unprivileged users > > having access to all the database procedure source code. > > That some "larger organizations" choose to use the known-unsafe method > of security by obscurity is not a reason for anybody here to expend > any effort helping them persist in this illusion: quite the opposite, > in fact. "Larger organizations" are likely to have security needs > which they actually need to address, not to pretend they've addressed > while actually making things easy for attackers. I think you are confusing 'security by obscurity' with 'security by policy'. The reasons for not allowing non-privileged users within your company access to your source codes are highly nuanced. Generally, though, on the systems I admin information is doled out on a 'need to know' basis. The data in the database is managed in a highly controlled fashion, why not the code? Non technical users have no business looking at the code I write because their bosses (not me) prefer it that way. End of story. observe: C:\svn\rcsi\Etc>pg_dump -U test xxx pg_dump: SQL command failed pg_dump: Error message from server: ERROR: permission denied for relation pg_proc pg_dump: The command was: SELECT tableoid, oid, proname, prolang, pronargs, proargtypes, prorettypproacl, pronamespace, (select usename from pg_user where proowner = usesysid) as usename FROM pg_ oc WHERE NOT proisagg AND pronamespace != (select oid from pg_namespace where nspname = 'pg_catalo )