Petr Kavan wrote:

> I have database of company data, and some of them is table of
> information about employees. I need each employee to have access only
> to his own row. Postgre cannot do this by system of privileges,
> because that can give privileges only to whole tables.
> Possibility is to create a view for each employee that chooses only
> his data and give employee privileges to this view. But I am not sure
> if such number of views does not have some performance drawbacks or
> even if postgre can support it (I expect i can). I would need several
> tables protected like this and it can result in, say 1000 views in
> maximum.
> Because access to DB will go through PHP information system, other
> possibility to protect data is to let IS connect as more privileged
> than user really is, but let it retrieve only data for that user.
> View-approach seems far more clear than this, but im not sure if
> postgre can handle it without problems.

We do a similar thing tying user to per-row permissions. We have 1 view
per table, and it works fine.
I would recommend that you do something similar. Basically, just make
the view:

    SELECT * FROM user_table WHERE username=session_user;
REVOKE ALL FROM user_table;

security definer, means that the 'just_me' view will be executed as the
user who created the function (superuser).
The REVOKE ALL (my syntax might be wrong) prevents users from querying
the user tables directly.
The 'session_user' makes the view use the name of the actual connected
user (because of security definer, plain 'user' is the superuser)
This should allow a user to see only their own row in the database.
(Whichever rows that have username matching the connected name).

Now, this only works if the php front end connects specifically as the
given user (our system is setup to do this).

If you don't do it this way, you'll always be stuck with the IS layer
doing the restriction. Even if you create a view per user, if your PHP
layer has the right to look at other tables/views, it doesn't really help.

Good luck,

> Thanks for any reply :-)
> -----------------------------------------------------------
> Petr Kavan
> Database Development
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to