Re: SQL Property Graph Queries (SQL/PGQ)
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: SQL Property Graph Queries (SQL/PGQ) |
| Дата | |
| Msg-id | CAExHW5vpMd2QKCc5snwBXMEO+ykzLX3ZONnFn9Vg6yrMajg5Ag@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SQL Property Graph Queries (SQL/PGQ) (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: