Re: Restrict users from describing table

Поиск
Список
Период
Сортировка
От Michael Gill
Тема Re: Restrict users from describing table
Дата
Msg-id 3FF9050A.7080408@pointdx.com
обсуждение исходный текст
Ответ на Re: Restrict users from describing table  ("Andrew Dunstan" <andrew@dunslane.net>)
Ответы Re: Restrict users from describing table  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-hackers
Andrew Dunstan wrote:<br /><blockquote cite="mid4433.24.211.141.25.1073179123.squirrel@www.dunslane.net"
type="cite"><prewrap="">Michael Gill said: </pre><blockquote type="cite"><pre wrap="">Hello,
 

I've tried asking this question elsewhere and have not received a
satisfactory response.

I want to restrict users of my packaged database from directly
accessing  the data or reading the schema. I would provide access to
the read-only  data through functions (which works well in PG). I find
that \d will  expose the structure even though the user can't select:

movies=> \d codeset.first_table
Table "codeset.first_table"
Column |  Type   | Modifiers
--------+---------+-----------
col1   | integer |
col2   | integer |

movies=> select * from codeset.first_table;
ERROR:  permission denied for schema codeset

Is there any way to hide the structure from a particular user. I can't
use Postgresql if I can't encapsulate our intellectual property.
   </pre></blockquote><pre wrap="">
How will purchasers of your product run pg_dump if the superuser can't get
at the database schema?

The only way I can see to do this in general is some sort of filter layer
between the database and the user.

I'm mildly dubious of the IP value of a database schema, I must confess. I
guess you could also play funny games with the column and table names to
obscure the semantics, at the obvious cost of a maintenance nightmare.

cheers

andrew

 </pre></blockquote> The reason it would work in my situation is that the database provided to the customer is
read-only.It will only be upgraded by us, but the customer needs to access the data (indirectly). So, pg_dump is not
relevantto us in this scenario.<br /><br /> I think I have found the simple solution by separating the user from the
ownerof the tables, however!<br /><br /> I have simply created tables and functions in the owner's schema(A), then
grantedexecution to the other user(B). My brief testing indicates that B cannot access or describe A's objects, yet can
executethe function that retrieves data and returns a ref cursor.<br /><br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: glogy@centrum.cz (Jakub)
Дата:
Сообщение: How to retrieve functional index column names
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: psql \d option list overloaded