2012/6/4 Florian Pflug <f...@phlo.org>: > On Jun4, 2012, at 17:38 , Kohei KaiGai wrote: >> I'm worry about future maintenance issues, once we have >> RLSBYPASS permission or something user visible… > > I fear that without a generic way to disable RLS regardless which > RLS policy function is in effect, we're creating a huge maintenance > issue for DBAs. In a lot of shops, the DBA is responsible for a large > number of databases, each potentially using a completely different > approach to RLS and hence a completely different policy function. > Here is two problems around RLSBYPASS. The first is we have no idea to handle invalidation of prepared-statement when current user is switched, right now. The second is we can have another way to describe same RLS policy without PG original enhancement towards permission mechanism...
> Without something like RLSBYPASS, the DBA needs to have intimate > knowledge about the different RLS policies to e.g. guarantee that his > backups aren't missing crucial information, or that the replication > system indeed replicates all rows. > > With RLSBYPASS, all he needs to do is grant one privilege to his > replication or backup user. The rest can be left to the development > or support team for a specific application. > It seems to me you can define a function which implements site- specific security requirement (E.g "backup should not be prevented by RLS policy"), then include it as a part of RLS policy (or implicitly added by extensions, like sepgsql tries to do). These are the reason why I hesitate to go ahead with RLSBYPASS permission. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
