Thread: PostgreSQL

I would like restrict access to sensitive or restricted information for some users (eg. hide data of one or more
clientsfor some database users). 

PostgreSQL allows to create security policy as Row-Level Security, policies based on the querying user.


Are there any other alternatives to RLS, are there any better solutions??

What are  the advantages and disadvantages of RLS?

How much RLS will cause a decrease in database performance?

JK

Joseph Kennedy schrieb am 07.02.2023 um 12:02:
> I would like restrict access to sensitive or restricted information
> for some users (eg. hide data of one or more clients for some
> database users).
>
> PostgreSQL allows to create security policy as Row-Level Security,
> policies based on the querying user.
>
>
> Are there any other alternatives to RLS, are there any better
> solutions??

You can create a view layer and only grant access to the data through views
(and obviously revoke access to the tables directly)

Or allow access only through (set returning) functions

On Tue, 2023-02-07 at 12:36 +0100, Joseph Kennedy wrote:
> RLS policy it only affects to command as SELECT, INSERT, UPDATE, DELETE or
> can affects to operations on whole database, table like vacuum or reindex etc ?

No, that wouldn't make any sense.  Row Level Security determines who
is allowed to see or create which data.  Jobs like removing dead tuples
or rebuilding an index have nothing to do with that.

Besides, anything that requires the table owner or a superuser cannot
be reasonably controlled with row level security, because both the
table owner and a superuser are exempt from RLS anyway.

Yours,
Laurenz Albe

Thank you Laurenz, I just wanted to make sure.

Do you know any alternative solution to RLS ?

> Wiadomość napisana przez Laurenz Albe <laurenz.albe@cybertec.at> w dniu 07.02.2023, o godz. 15:34:
>
> On Tue, 2023-02-07 at 12:36 +0100, Joseph Kennedy wrote:
>> RLS policy it only affects to command as SELECT, INSERT, UPDATE, DELETE or
>> can affects to operations on whole database, table like vacuum or reindex etc ?
>
> No, that wouldn't make any sense.  Row Level Security determines who
> is allowed to see or create which data.  Jobs like removing dead tuples
> or rebuilding an index have nothing to do with that.
>
> Besides, anything that requires the table owner or a superuser cannot
> be reasonably controlled with row level security, because both the
> table owner and a superuser are exempt from RLS anyway.
>
> Yours,
> Laurenz Albe

On 2023-02-07 12:36:57 +0100, Joseph Kennedy wrote:
> RLS policy it only affects to command as SELECT, INSERT, UPDATE, DELETE or can
> affects to operations on whole database, table like vacuum or reindex etc ?

"Row level security" works, as the name implies at the row level.
Tables, schemas and databases and covered by the "usual" SQL privilege
system.

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Greetings,

* Joseph Kennedy (joseph.kennedy.486@gmail.com) wrote:
> Thank you Laurenz, I just wanted to make sure.
>
> Do you know any alternative solution to RLS ?

... to do what?  If you want to limit the set of rows that a given user
can see, RLS is how to do that.  If you want to limit the schemas or
tables that a user can see, that isn't possible in PG today (though
there was some interest a while back in making that work via RLS on the
catalogs which you might be able to find).

Thanks,

Stephen

On Thu, 2023-02-09 at 09:54 +0100, Joseph Kennedy wrote:
> As I wtote, I would like restrict access to sensitive or restricted information
> for some users (eg. hide data of one or more clients for some database users).
>
> My question is: do you know some other solution to do that ? 

It is easy to hide data from users: use permissions or row level security.

It is impossible to hide metadata from users, but we don't consider that a problem.

If you want that, use a database or a database cluster per user.

Yours,
Laurenz Albe

> Wiadomość napisana przez Laurenz Albe <laurenz.albe@cybertec.at> w dniu 09.02.2023, o godz. 16:42:
>
> On Thu, 2023-02-09 at 09:54 +0100, Joseph Kennedy wrote:
>> As I wtote, I would like restrict access to sensitive or restricted information
>> for some users (eg. hide data of one or more clients for some database users).
>>
>> My question is: do you know some other solution to do that ?
>
> It is easy to hide data from users: use permissions or row level security.
>
> It is impossible to hide metadata from users, but we don't consider that a problem.
>
> If you want that, use a database or a database cluster per user.
>
> Yours,
> Laurenz Albe

I have one more question on this topic regarding Row Level Security.

I would like to hide some rows for users who should have full rights to database eg. create Index, drop table, create
tabeletc. but e.g.  create index can be done by owner or superusers but they are bypassed by Row Level Security.  

Is possible to use RLS for users who should have full rights to database ?

On Sun, 2023-04-02 at 23:21 +0200, Joseph Kennedy wrote:
> I have one more question on this topic regarding Row Level Security.
>
> I would like to hide some rows for users who should have full rights to database
> eg. create Index, drop table, create tabel etc. but e.g.  create index can be
> done by owner or superusers but they are bypassed by Row Level Security.
>
> Is possible to use RLS for users who should have full rights to database ?

If "full rights" implies dropping tables, the user must either be the owner
of these tables or a superuser.  You cannot use Row Level Security with a
superuser.  You can use ALTER TABLE ... FORCE ROW LEVEL SECURITY, so that
Row Level Security applies to the table owner as well, but you cannot keep
the owner from disabling that setting.

Yours,
Laurenz Albe