On Tue, Dec 2, 2025 at 3:30 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Nov 25, 2025 at 7:22 PM Peter Eisentraut <peter@eisentraut.org> 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.
--
Best Wishes,
Ashutosh Bapat
