From: | "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | viewing source code |
Date: | 2007-12-22 19:46:31 |
Message-ID: | 1A6E6D554222284AB25ABE3229A92762112A6B@nrtexcus702.int.asurion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane indicated this thread should be moved here. Instead of asking for
what I consider the solution, let me propose a real business case and you
guys tell me how best to handle it.
I am building an Enterprise Data Warehouse with PostgreSQL. BTW, I love
this database. I will have data from all over the company housed in it and
a variety of business users from all over the company as well.
Users Communities
Call Center
Finance
Sales
IT
Marketing
HR
Security
Major Feature 1: These users will be using common dimensions and fact tables
that are unique to each department. PostgreSQL security will handle this
just fine.
Major Feature 2: Users will be able to load their own data into the data
warehouse and secure this to their department. PostgreSQL security will
handle this just fine.
Major Feature 3: Users will build their own functions to manipulate their
own data and share the output with their department. PostgreSQL security
currently does not secure the functions they write so the feature is not
fully met.
The user community is not highly technical and they are not looking for an
obfuscation solution. They are looking for simple security to their code
they write in pl/pgsql that is similar if not the same as the security for
protecting their data.
How best can I achieve Major Feature 3?
Examples of what would be in the functions that need to be secured:
1. HR could have pay and performance calculations that they don't want
shared with other departments.
2. Finance could have earnings calculations they don't want to share with
marketing.
3. Security could have functions to identify network abusers.
4. Finance could have fraud and abuse calculations they don't want to share
with the call center.
Building a database per department isn't feasible. It would require a vast
amount of data replication and duplication. We want an Enterprise solution.
One solution already proposed is to create a view in place of the pg_proc
table. The source code column would be protected in a similar fashion to
pg_stat_activity.current_query. This seems like a great solution to me and
it would meet our Major Feature 3.
Jon
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2007-12-22 20:03:03 | Re: viewing source code |
Previous Message | Tom Lane | 2007-12-22 19:21:42 | Re: Spoofing as the postmaster |