Re: ASYNC Privileges proposal
От | Chris Farmiloe |
---|---|
Тема | Re: ASYNC Privileges proposal |
Дата | |
Msg-id | CAJNjj-uj5207Du4fEagq3YFTCCD2e+xrdvj8DW71YHeQO_yFOg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ASYNC Privileges proposal (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
In fairness NOTIFY has only had a payload since v9 (maybe 8.4?), and the issue of trust is mainly tied to data leaking from the payload, so I suspect I won't be last person to request this as people re-visit NOTIFY :)
Chris
...but I totally get your point of course.
My first thought was also that having control at the channel-level would be ideal, but that would be a huge implementation change by the looks of things, would certainly affect performance a great deal more and would not really give much more benefit that could be attained with database-level control + a "SECURITY DEFINER" function.
Chris
On 20 May 2013 03:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Chris Farmiloe <chrisfarms@gmail.com> writes:TBH, nobody has complained about this in the fifteen-plus years that
> I find the current LISTEN / NOTIFY rather limited in the context of
> databases with multiple roles. As it stands it is not possible to restrict
> the use of LISTEN or NOTIFY to specific roles, and therefore notifications
> (and their payloads) cannot really be trusted as coming from any particular
> source.
LISTEN has been around. I'm dubious about adding privilege-checking
overhead for everybody to satisfy a complaint from one person.... and if I did think that there were an issue here, I doubt I'd think
> I'd like to propose a new ASYNC database privilege that would control
> whether a role can use LISTEN, NOTIFY and UNLISTEN statements and the
> associated pg_notify function.
that a privilege as coarse-grained as that would fix it. Surely you'd
want per-channel privileges if you were feeling paranoid about this,
not to mention separate read and write privileges. But the demand for
that just isn't out there.
regards, tom lane
В списке pgsql-hackers по дате отправления: