Re: crypting prosrc in pg_proc

From: Sergiy Vyshnevetskiy <serg(at)vostok(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: crypting prosrc in pg_proc
Date: 2007-08-10 20:03:10
Message-ID: Pine.LNX.4.64.0708102253150.28860@uanet.vostok.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 10 Aug 2007, Gregory Stark wrote:

> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
>
>> Obfuscation doesn't really work, it just makes big wigs in companies
>> *think* it's not easily reversible.
>>
>> There is no real security. With enough time and experience, anything
>> can be broken.
>
> But that said, I wonder if having something may be useful legally for some
> users.
>
> If someone just went and did "select * from pg_proc" they could claim they
> weren't violating their EULA or any protection you had put in place. If they
> went through the trouble having to de-obfuscate it then you would have a
> strong DMCA claim in the US.

We can split pg_proc into pg_procinfo and pg_procsrc.

pg_procinfo contains all information about function except source code and
is readable to all.

pg_procsrc has the source and readable only to system and superusers.

pg_proc is a view that joins the two. If database developer wants to limit
user access, they add conditions to the view as necessary, e.g.

proowner in ('postgres',current_user)

or whatever they want.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-08-10 21:34:07 Re: change name of redirect_stderr?
Previous Message Simon Riggs 2007-08-10 19:59:39 Re: Unexpected VACUUM FULL failure