* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: > > Yeah, I was thinking something like this could work, but I would go > > further. Suppose you had separate GRANTable privileges for direct > > access to individual tables, bypassing RLS, e.g. > > > > GRANT DIRECT SELECT|INSERT|UPDATE|DELETE ON table_name TO role_name > > So, is this one new privilege (DIRECT) or four separate new privileges > that are variants of the existing privileges (DIRECT SELECT, DIRECT > INSERT, DIRECT UPDATE, DIRECT DELETE)?
I had taken it to be a single privilege, but you're right, it could be
done for each of those.. I really don't think we have the bits for more
than one case here though (if that) without a fair bit of additional
rework. I'm not against that rework (and called for it wayyy back when
I proposed the TRUNCATE privilege, as I recall) but that's a whole
different challenge and no small bit of work..
> > Actually, given the fact that the majority of users won't be using
> > RLS, I would be tempted to invert the above logic and have the new
> > privilege be for LIMITED access (via RLS quals). So a user granted the
> > normal SELECT privilege would be able to bypass RLS, but a user only
> > granted LIMITED SELECT wouldn't.
>
> Well, for the people who are not using RLS, there's no difference
> anyway. I think it matters more what users of RLS will expect from a
> command like GRANT SELECT ... and I'm guessing they'll prefer that RLS
> always apply unless they very specifically grant the right for RLS to
> not apply. I might be wrong, though.
The preference from the folks using RLS that I've talked to is
absolutely that it be applied by default for all 'normal' (eg:
non-pg_dump) sessions.
Thanks,
Stephen
signature.asc
Description: Digital signature
