On Thu, Dec 4, 2025 at 2:23 AM Ashutosh Bapat <[email protected]> wrote: > On Tue, Dec 2, 2025 at 3:30 PM Ashutosh Bapat > <[email protected]> wrote: > > On Tue, Nov 25, 2025 at 7:22 PM Peter Eisentraut <[email protected]> > > wrote: > > > > > > > > - I'm not so sure about the semantics chosen in the patch "Access > > > permissions on property graph". I think according to the SQL standard, > > > once you have access to the property graph, you don't need access to the > > > underlying tables as well. I guess you did this to align with how views > > > work? We might need to think about this a bit more, and document > > > whatever the conclusion is. But for now it's just small amount of code > > > affected. > > > > Section 7.1 Access rules seem to just require that the session user > > should have SELECT privileges on the property graph. I didn't find an > > answer to the question: What privileges should be used while accessing > > the element tables. Application of RLS policies depends upon the > > answer, for example. They can be either the owner's privileges > > (security_definer semantics) or the privileges of session user > > (security_invoker semantics). A view can define what data it exposes > > precisely upto a row and column; hence a security_definer view can be > > made safer. But a property graph can not constrain rows that it > > exposes. So I feel, by default, security_invoker semantics are safer > > for property graphs. We may support security_definer semantics later, > > but it has to be an explicit choice by the user. > > A view definition contains all the functions, operators and objects > which will be accessed when executing the view. However, when creating > a property graph, the user creating it, can not restrict the > functions, operators or other objects which will be used in the > GRAPH_TABLE clause. If we allow security_definer property graphs, a > malicious user can use it easily to escalate privileges. So, I think > supporting security_defined semantic on a property graph is very > dangerous. We should allow only security_invoker semantics.
+1 for invoker semantics as the default initially, and work on adding a security-definer option if that’s needed in the future, which I imagine might be trickier than what we have for views, not sure. In your commit message: 4. We have not implemented security definer property graphs since SQL/PGQ standard does not mention those. My reading of the access rules is that, from the caller’s point of view, the standard expects behavior that is quite close to security-definer semantics -- once the session user has SELECT on the property graph, they do not need privileges on the element tables. Is that also how you read it, or do you see the standard as intentionally leaving room for invoker semantics like you've currently implemented? -- Thanks, Amit Langote
