Re: Hot to restrict access to subset of data

I would strongly suggest that you create a database specific user,
one that has read/write access within this database, and that your
application use that user instead of the pg super user.

In general, the "super user" should never be used, except for
specific administrative tasks. This holds true for Windows
Administrator, Unix root, and postgresql's postgres users. If your
application runs under a single user to the database, then that
single user should be one that you create specifically for that
purpose, and not the postgres user.

Greg

On Jul 3, 2005, at 1:19 PM, Andrus Moor wrote:

> Greg,
>
> using views would be nice.
>
> I have also a add privilege which allows to add only new documents.
> I think
> that this requires writing triggers in Postgres.
>
> This seems to be a lot of work.
> I do'nt have enough knowledge to implement this in Postgres.
>
> So it seems to more reasonable to run my application as Postgres
> superuser
> and implement security in application.
>
> Andrus.
>
> "Gregory Youngblood" <gsyoungblood(at)mac(dot)com> wrote in message
> news:CB2AF562-2A4D-4A9C-BC2A-E55C9029FB56(at)mac(dot)com(dot)(dot)(dot)
>
>> I believe you can probably use views to accomplish this.
>>
>> You create a view that is populated based on their username. Then you
>> remove access to the actual table, and grant access to the view.
>>
>> When people look at the table, they will only see the data in the
>> view
>> and will not have access to the other.
>>
>> Of course, this assumes they do not need to update the data. I've not
>> played around with rules to make a view allow updates. I believe
>> it is
>> possible, I've just not done it yet. This also assumes you have data
>> somewhere that maps user names to document types.
>>
>> The postgresql docs should provide the syntax and additional
>> details if
>> you want to try this. I have also found pgAdmin very useful to
>> create
>> views and other schema related activities as well.
>>
>> Hope this helps,
>> Greg
>>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>>
>>
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>