I have similar patch and it works. There is two isues:
* we missing column in pg_proc about state (not all procedures are
obfuscated), I solved it for plpgsl with using probin.
* decrypt is expensive on language handler level. Every session have
to do it again and again, better decrypt in system
On Dec 21, 2007 3:18 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
I have similar patch and it works. There is two isues:
* we missing column in pg_proc about state (not all procedures are
obfuscated), I solved it for plpgsl with using probin.
I was hoping to avoid making any catalog or other
Bruce Momjian wrote:
Is this a TODO?
---
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
It's quite a good idea, because it
On Dec 21, 2007 9:34 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Is this a TODO?
I don't think so, at least not yet (it's not clear what if anything
there is to do).
see: http://archives.postgresql.org/pgsql-hackers/2007-12/msg00788.php
merlin
---(end of
On 21/12/2007, Merlin Moncure [EMAIL PROTECTED] wrote:
On Dec 21, 2007 3:18 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
I have similar patch and it works. There is two isues:
* we missing column in pg_proc about state (not all procedures are
obfuscated), I solved it for plpgsl with using
Is this a TODO?
---
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
It's quite a good idea, because it has more than zero
On Fri, Dec 21, 2007 at 12:09:28AM -0500, Merlin Moncure wrote:
Maybe a key management solution isn't required. If, instead of
strictly wrapping a language with an encryption layer, we provide
hooks (actors) that have the ability to operate on the function body
when it arrives and leaves
On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote:
whether there is a useful policy for it to implement. Andrew Sullivan
argued upthread that we cannot get anywhere with both keys and encrypted
function bodies stored in the same database (I hope that's an adequate
summary of his
It seems like a lot of people only saw hide source code in the
original message, and then went off on tangents that don't have
anything to do with the request.
Again:
On 12/14/07, Roberts, Jon [EMAIL PROTECTED] wrote:
Is it possible yet in PostgreSQL to hide the source code of functions from
I wrote:
That's it. A very simple problem.
It was hinted to me off-list that my mail was fanning the flames, so
to clarify: when I say things like the above, I mean conceptually.
I think there might be a shared pool of knowledge that says it's
anything but simple in practical terms, but that
Trevor Talbot [EMAIL PROTECTED] writes:
Something that looks a lot like encryption of the entire database is
more likely to succeed politically than a simple addition to
PostgreSQL's existing role-based security model? Really?
I guess that you have failed to understand any of the discussion.
On Thu, Dec 20, 2007 at 02:02:57PM -0600, Roberts, Jon wrote:
I'm tired of arguing. You win. I still say this I a needed feature if you
want adoption for enterprise level databases in larger companies. The
security out of the box is not enough
What a classic I want this, and if it isn't
.
Harris; Bill Moran; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
Roberts, Jon escribió:
The more I thought about a counter proposal to put views on pg_proc, I
realized that isn't feasible either. It would break functionality of
pgAdmin because users
On Dec 20, 2007 9:07 AM, Roberts, Jon [EMAIL PROTECTED] wrote:
So your suggestion is first to come up with a query that dynamically checks
permissions and create a view for it. Secondly, change pgAdmin to reference
this view in place of pg_proc. Actually, it should be extended to all
This
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 8:30 AM
To: Roberts, Jon
Cc: Alvaro Herrera; Trevor Talbot; Joshua D. Drake; Kris Jurka; Jonah H.
Harris; Bill Moran; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing
Roberts, Jon wrote:
This really is a needed feature to make PostgreSQL more attractive to
businesses. A more robust security model that better follows commercial
products is needed for adoption.
I would argue that commercial products need to get a clue and stop
playing bondage with their
-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
On Dec 20, 2007 9:07 AM, Roberts, Jon [EMAIL PROTECTED]
wrote:
So your suggestion is first to come up with a query that dynamically
checks
permissions and create a view for it. Secondly, change pgAdmin to
reference
this view
Moran; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
On Dec 20, 2007 9:07 AM, Roberts, Jon [EMAIL PROTECTED] wrote:
So your suggestion is first to come up with a query that dynamically
checks
permissions and create a view for it. Secondly, change pgAdmin
On Dec 20, 2007 12:39 PM, A.M. [EMAIL PROTECTED] wrote:
On Dec 20, 2007, at 11:30 AM, Roberts, Jon wrote:
On Dec 20, 2007 9:07 AM, Roberts, Jon [EMAIL PROTECTED]
wrote:
So your suggestion is first to come up with a query that dynamically
checks
permissions and create a view for it.
Roberts, Jon escribió:
So your suggestion is first to come up with a query that dynamically checks
permissions and create a view for it. Secondly, change pgAdmin to reference
this view in place of pg_proc. Actually, it should be extended to all
objects in the database, not just pg_proc. If
On 12/20/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Roberts, Jon wrote:
This really is a needed feature to make PostgreSQL more attractive to
businesses. A more robust security model that better follows commercial
products is needed for adoption.
I would argue that commercial products
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Dec 2007 10:47:53 -0800
Trevor Talbot [EMAIL PROTECTED] wrote:
This feature as it is called can be developed externally and has
zero reason to exist within PostgreSQL. If the feature has the
level of demand that people think that
-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 10:40 AM
To: Roberts, Jon
Cc: 'Trevor Talbot'; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill
Moran; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Dec 2007 13:45:08 -0600
Roberts, Jon [EMAIL PROTECTED] wrote:
I think it is foolish to not make PostgreSQL as feature rich when it
comes to security as the competition because you are idealistic when
it comes to the concept of source
-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 1:54 PM
To: Roberts, Jon
Cc: 'Trevor Talbot'; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill
Moran; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
Joshua D. Drake escribió:
I don't know that it needs to be that extensive. I noted elsewhere in
the thread the idea of a plpgsql_s. I think that is an interesting
idea. I just don't think it needs to be incorporated into
postgresql-core.
I don't think that makes any kind of sense. Hiding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 20 Dec 2007 14:02:57 -0600
Roberts, Jon [EMAIL PROTECTED] wrote:
I'm tired of arguing. You win. I still say this I a needed feature
if you want adoption for enterprise level databases in larger
companies. The security out of the box is
On Dec 20, 2007 3:07 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't think that makes any kind of sense. Hiding prosrc should happen
on a entirely different level from the language on which the function is
written. It's a completely orthogonal decision. Besides, you probably
don't want
On Thu, Dec 20, 2007 at 03:35:42PM -0500, Merlin Moncure wrote:
Key management is an issue but easily solved. Uber simple solution is
to create a designated table holding the key(s) and use classic
permissions to guard it.
Any security expert worth the title would point and laugh at that
On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrote:
Businesses use databases like crazy. Non-technical people write their own
code to analyze data. The stuff they write many times is as valuable as the
data itself and should be protected like the data. They don't need or want
many
[EMAIL PROTECTED] (Roberts, Jon) writes:
I think it is foolish to not make PostgreSQL as feature rich when it
comes to security as the competition because you are idealistic when
it comes to the concept of source code. PostgreSQL is better in
many ways to MS SQL Server and equal to many
On Thu, Dec 20, 2007 at 03:24:34PM -0600, Roberts, Jon wrote:
Actually, PostgreSQL already has column level security for pg_stat_activity.
Not exactly. pg_stat_activity is a view.
But I think someone suggested upthread experimenting with making pg_proc
into a view, and making the real
On Dec 20, 2007 3:52 PM, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, Dec 20, 2007 at 03:35:42PM -0500, Merlin Moncure wrote:
Key management is an issue but easily solved. Uber simple solution is
to create a designated table holding the key(s) and use classic
permissions to guard it.
Merlin Moncure escribió:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
Right. But do you agree that it is separate from having hidden prosrc?
If we can complete a design then let's shot that way, and aim at
encryption sometime in the future :-)
I have to
On Thu, Dec 20, 2007 at 05:04:33PM -0500, Merlin Moncure wrote:
right, right, thanks for the lecture. I am aware of various issues
with key management.
Sorry to come off that way. It wasn't my intention to lecture, but rather
to try to stop dead a cure that, in my opinion, is rather worse
On Thu, 20 Dec 2007, Roberts, Jon wrote:
I still say this I a needed feature if you want adoption for enterprise
level databases in larger companies.
It is to some people, and Joshua's opinion is, like everybody else's, just
one person's view on what's important.
The security out of the
On Dec 20, 2007 5:28 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
Right. But do you agree that it is separate from having hidden prosrc?
If we can complete a design then let's shot that way, and aim at
Merlin Moncure [EMAIL PROTECTED] writes:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
It's quite a good idea, because it has more than zero chance of
succeeding politically in the community.
The fundamental reason why preventing access to pg_proc.prosrc
wrapping pl/pgsql with encryptor/decryptor
It's quite a good idea, because it has more than zero chance of
succeeding politically in the community.
It's additionally a good idea because the other big database is using the
same approach. Easier sell to phb.
Harald
--
GHUM Harald Massa
On Dec 20, 2007 6:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.
So if you want something other than endless arguments to happen,
come up with a nice key-management design
Merlin Moncure [EMAIL PROTECTED] writes:
On Dec 20, 2007 6:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
So if you want something other than endless arguments to happen,
come up with a nice key-management design for encrypted function
bodies.
Maybe a key management solution isn't required. If,
On Dec 21, 2007 12:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
On Dec 20, 2007 6:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
So if you want something other than endless arguments to happen,
come up with a nice key-management design for encrypted function
-Original Message-
From: Trevor Talbot [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 19, 2007 9:45 AM
To: Joshua D. Drake
Cc: Roberts, Jon; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill Moran;
pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
; Bill Moran; Joshua D. Drake; pgsql-
[EMAIL PROTECTED]
Subject: Re: [PERFORM] viewing source code
On Mon, 17 Dec 2007, Merlin Moncure wrote:
the table is pg_proc. you have to revoke select rights from public
and the user of interest. be aware this will make it very difficult
Roberts, Jon escribió:
Revoking pg_proc isn't good for users that shouldn't see other's code but
still need to be able to see their own code.
So create a view on top of pg_proc restricted by current role, and grant
select on that to users.
--
Alvaro Herrera
Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2007 12:27 PM
To: Roberts, Jon
Cc: 'Kris Jurka'; Merlin Moncure; Jonah H. Harris; Bill Moran; Joshua D.
Drake; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
Roberts, Jon escribió
Roberts, Jon wrote:
So you are saying I need to create a view per user to achieve this? That
isn't practical for an enterprise level database.
Surely you'd just have:
CREATE VIEW ... AS SELECT * FROM pg_proc WHERE author=CURRENT_USER
--
Richard Huxton
Archonet Ltd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Dec 2007 10:05:46 -0600
Roberts, Jon [EMAIL PROTECTED] wrote:
If we are talking about enhancement requests, I would propose we
create a role that can be granted/revoked that enables a user to see
dictionary objects like source code.
Roberts, Jon escribió:
So you are saying I need to create a view per user to achieve this? That
isn't practical for an enterprise level database.
No -- that would be quite impractical indeed. I'm talking about
something like
revoke all privileges on pg_proc from public;
create view
: [PERFORM] viewing source code
On Dec 14, 2007 2:03 PM, Bill Moran [EMAIL PROTECTED]
wrote:
I disagree here. If they're connecting remotely to PG, they have no
direct access to the disk.
pg_read_file?
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB
On Dec 17, 2007 8:11 AM, Roberts, Jon [EMAIL PROTECTED] wrote:
Alvaro Herrera pointed out that pg_read_file requires superuser access which
these users won't have so revoking access to the function code should be
possible.
Joshua D. Drake suggested revoking pg_proc but that isn't the source
: Jonah H. Harris [mailto:[EMAIL PROTECTED]
Sent: Friday, December 14, 2007 3:04 PM
To: Bill Moran
Cc: Joshua D. Drake; Roberts, Jon; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
On Dec 14, 2007 2:03 PM, Bill Moran [EMAIL PROTECTED]
wrote:
I disagree here
On Mon, 17 Dec 2007, Merlin Moncure wrote:
the table is pg_proc. you have to revoke select rights from public
and the user of interest. be aware this will make it very difficult
for that user to do certain things in psql and (especially) pgadmin.
it works.
a better solution to this problem
In an ideal world, if a user can't modify a function, he/she shouldn't
be
able to see the source code. If the user can execute the function, then
the
user should be able to see the signature of the function but not the
body.
I doubt that's going to happen. Mainly because I disagree
In response to Roberts, Jon [EMAIL PROTECTED]:
Is it possible yet in PostgreSQL to hide the source code of functions from
users based on role membership? I would like to avoid converting the code
to C to secure the source code and I don't want it obfuscated either.
In an ideal world, if
In response to Roberts, Jon [EMAIL PROTECTED]:
In an ideal world, if a user can't modify a function, he/she shouldn't
be
able to see the source code. If the user can execute the function, then
the
user should be able to see the signature of the function but not the
body.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Dec 2007 11:18:49 -0500
Bill Moran [EMAIL PROTECTED] wrote:
That is like saying anyone that has rights to call a web service
should be able to see the source code for it.
I think that's a good idea. If vendors were forced publish
Joshua D. Drake wrote:
However, in the current configuration, all users with permission to
log in can see all source code. They don't have rights to execute
the functions but they can see the source code for them. Shouldn't
I be able to revoke both the ability to execute and the
In response to Joshua D. Drake [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Dec 2007 11:18:49 -0500
Bill Moran [EMAIL PROTECTED] wrote:
That is like saying anyone that has rights to call a web service
should be able to see the source code for it.
Roberts, Jon [EMAIL PROTECTED] schrieb:
Is it possible yet in PostgreSQL to hide the source code of functions from
users based on role membership? I would like to avoid converting the code
to C to secure the source code and I don't want it obfuscated either.
Some days ago i have seen a
On Dec 14, 2007 2:03 PM, Bill Moran [EMAIL PROTECTED] wrote:
I disagree here. If they're connecting remotely to PG, they have no
direct access to the disk.
pg_read_file?
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation| fax:
To: Bill Moran
Cc: Joshua D. Drake; Roberts, Jon; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] viewing source code
On Dec 14, 2007 2:03 PM, Bill Moran [EMAIL PROTECTED]
wrote:
I disagree here. If they're connecting remotely to PG, they have no
direct access to the disk
On Dec 14, 2007 4:24 PM, Andreas Kretschmer [EMAIL PROTECTED] wrote:
Some days ago i have seen a pl/pgsql- code - obfuscator, iirc somewhere
under http://www.pgsql.cz/index.php/PostgreSQL, but i don't know how it
works, and i can't find the correkt link now, i'm sorry...
I started one awhile
Roberts, Jon escribió:
I'm not familiar at all with pg_read_file. Is it wide open so a user can
read any file they want? Can you not lock it down like utl_file and
directories in Oracle?
That function is restricted to superusers.
--
Alvaro Herrera Developer,
64 matches
Mail list logo
