pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: John Arbash Meinel <john@arbash-meinel.com>
To: Petr Kavan <petr.kavan@marekmicro.cz>
Cc: pgsql-performance@postgresql.org
Subject: Re: How many views is ok?
Date: Sun, 14 Aug 2005 19:22:12 -0500
Message-ID: <42FFE034.2020809@arbash-meinel.com> (raw)
In-Reply-To: <001a01c59f0a$8e8d9560$de01a8c0@kavan>
References: <001a01c59f0a$8e8d9560$de01a8c0@kavan>

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:

CREATE VIEW just_me SECURITY DEFINER AS
    SELECT * FROM user_table WHERE username=session_user;
REVOKE ALL FROM user_table;
GRANT SELECT TO just_me TO PUBLIC;

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,
John
=:->

>
> Thanks for any reply :-)
>
> -----------------------------------------------------------
> Petr Kavan
> Database Development
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq
>

Attachments:

  signature.asc (application/pgp-signature, 255B) download

view thread (4+ messages)  latest in thread

Message-ID: <42FFE034.2020809@arbash-meinel.com>
Permalink:  ../42FFE034.2020809@arbash-meinel.com/
Also on:    postgresql.org/message-id/42FFE034.2020809@arbash-meinel.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: john@arbash-meinel.com, petr.kavan@marekmicro.cz
  Subject: Re: How many views is ok?
  In-Reply-To: <42FFE034.2020809@arbash-meinel.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox