Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Apr 19, 2021 at 4:32 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <n...@leadboat.com> wrote: > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for > > >> setting LEAKPROOF. I would not consult datdba, because datdba currently > > >> has > > >> no special read abilities. It feels too weird to let BYPASSRLS start > > >> affecting non-RLS access controls. A reasonable person may assume that > > >> BYPASSRLS has no consequences until someone uses CREATE POLICY. That > > >> said, I > > >> wouldn't be horrified if BYPASSRLS played a part. BYPASSRLS, like > > >> pg_read_all_data, clearly isn't something to grant lightly. > > > > > I agree that datdba doesn't seem like quite the right thing, but I'm > > > not sure I agree with the rest. How can we say that leakproof is a > > > non-RLS access control? Its only purpose is to keep RLS secure, so I > > > guess I'd be inclined to think that of the two, BYPASSRLS is more > > > closely related to the topic at hand. > > > > Umm ... I'm pretty sure LEAKPROOF also affects optimization around > > "security barrier" views, which I wouldn't call RLS. Out of these > > options, I'd prefer granting the ability to pg_read_all_data. > > Oops, I forgot about security_barrier views, which is rather > embarrassing since I committed them. So, yeah, I agree: > pg_read_all_data is better.
I'm not really sure that attaching it to pg_read_all_data makes sense.. In general, I've been frustrated by the places where we lump privileges together rather than having a way to distinctly GRANT capabilities independently- that's more-or-less exactly what lead me to work on implementing the role system in the first place, and later the predefined roles. I do think it's good to reduce the number of places that require superuser, in general, but I'm not sure that marking functions as leakproof as a non-superuser makes sense. Here's what I'd ask Andrey- what's the actual use-case here? Are these cases where users are actually adding new functions which they believe are leakproof where those functions don't require superuser already to be created? Clearly if they're in a untrusted language and you have to be a superuser to install them in the first place then they should just mark the function as leakproof when they install it. If these are trusted language functions, I'd be curious to actually see them as I have doubts about if they're actually leakproof.. Or is the actual use-case here that they just want to mark functions we know aren't leakproof as leakproof anyway because they aren't getting the performance they want? If it's the latter, as I suspect it is, then I don't really think the use-case justifies any change on our part- the right answer is to make those functions actually leakproof, or write ones which are. Thanks, Stephen
signature.asc
Description: PGP signature
