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 im
"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 discuss
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 h
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 fro
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 po
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 p
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 broadcast
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
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
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 oth
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 c
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 encr
"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 req
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-mana
>
> 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 Mass
"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.pro
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
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 box
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 th
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 t
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
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 tab
> -Original Message-
> From: Andrew Sullivan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 20, 2007 3:04 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] viewing source code
>
> On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrot
[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 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
> m
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 th
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
-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
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. Hidin
> -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
> Subjec
-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 sou
> -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
>
-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
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
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.
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 creat
Joshua D. Drake; Kris Jurka; Jonah H.
> > Harris; Bill 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 wi
-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
thi
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 u
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
> ref
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
Thi
; Joshua D. Drake; Kris Jurka; Merlin Moncure; Jonah H.
> 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
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 couldn't view their source code with the tool.
What's wrong with patching pgAdmin?
--
Alvaro Herrera
> -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: [PE
On 12/18/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> 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 obj
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 limited_
-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 cod
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
--
-Original 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: [PERFO
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 Herreraht
> Cc: Roberts, Jon; Jonah H. Harris; 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
>
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
ssage-
From: 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:
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 so
sql-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.
>
>
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, http
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 awhi
7 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. If they're connecting remotely
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: 732.331
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 c
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
-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 pu
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
>
> > 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
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 wo
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 a user can't modify a function, he/she shouldn't be
ab
68 matches
Mail list logo
