Thread: Re: protecting prosrc (was Re: [GENERAL] USAGE on schema allowed by

NOTE: redirecting to hackers

On Mon, 2002-12-02 at 12:50, Joe Conway wrote:
> Tom Lane wrote:
> > For example, something I've heard repeatedly is that people would like to
> > hide the source code of their SQL or PLxxx functions from users who are
> > nonetheless allowed to call those functions.  A row-wise selective view of
> > pg_proc can't fix that.  In many cases it's less than clear which rows of
> > which catalogs to hide anyway.
> 
> It wouldn't be terribly difficult to encrypt prosrc with 3des (or maybe aes) 
> using the owner's passwd from pg_shadow. We would need a new bool column in 
> pg_proc (proisencrypted?) and some logic in fmgr.c.
> 
> Is there sufficient interest to justify the effort?
> 

I think this would be a good idea, though there becomes a question of
what type of performance hit comes into play when doing this. I suppose
if you have an option whether to encrypt it or not that would help.  One
other thing is that it needs to be "decryptable" by owners and
superusers. 

Robert Treat

> > It wouldn't be terribly difficult to encrypt prosrc with 3des (or maybe
aes)
> > using the owner's passwd from pg_shadow. We would need a new bool column
in
> > pg_proc (proisencrypted?) and some logic in fmgr.c.
> >
> > Is there sufficient interest to justify the effort?
> >
>
> I think this would be a good idea, though there becomes a question of
> what type of performance hit comes into play when doing this. I suppose
> if you have an option whether to encrypt it or not that would help.  One
> other thing is that it needs to be "decryptable" by owners and
> superusers.

Surely a more generic column privileges implementation would be better?

Chris

Robert Treat wrote:
> NOTE: redirecting to hackers

good idea!

> I think this would be a good idea, though there becomes a question of
> what type of performance hit comes into play when doing this. I suppose
> if you have an option whether to encrypt it or not that would help.  One
> other thing is that it needs to be "decryptable" by owners and
> superusers. 

For sure -- I would not propose doing this unless it was an optional thing.

Joe

Christopher Kings-Lynne wrote:
>>I think this would be a good idea, though there becomes a question of
>>what type of performance hit comes into play when doing this. I suppose
>>if you have an option whether to encrypt it or not that would help.  One
>>other thing is that it needs to be "decryptable" by owners and
>>superusers.
> 
> Surely a more generic column privileges implementation would be better?

I think column privileges is orthogonal to this issue. The ability to 
"protect" stored procedure or package source is common among at least the 
commercial databases I've worked with (as is column level grants).

Joe