From: | Chris Farmiloe <chrisfarms(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ASYNC Privileges proposal |
Date: | 2013-06-27 09:49:25 |
Message-ID: | CAJNjj-u5nPBQyrFwGvGjToys=w29-WoevVie8btf6WRn=eW=1w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
So I would think that if this was to go further then "channels" would need
to be more of a first class citizen and created explicitly, with CREATE
CHANNEL, DROP CHANNEL etc:
CREATE CHANNEL channame;
GRANT LISTEN ON CHANNEL channame TO rolename;
GRANT NOTIFY ON CHANNEL channame TO rolename;
LISTEN channame; -- OK
NOTIFY channame, 'hi'; -- OK
LISTEN xxxx; -- exception: no channel named "xxxx"
NOTIFY xxxx, 'hi'; -- exception: no channel named "xxxx"
Personally I think explicitly creating channels would be beneficial; I have
hit issues where an typo in a channel name has caused a bug to go unnoticed
for a while.
....But of course this would break backwards compatibility with the current
model (with implicit channel names) so unless we wanted to force everyone
to add "CREATE CHANNEL" statements during their upgrade then, maybe there
would need to be some kind of system to workaround this....
Possibly some kind of "catch-all" channel, that enables implicit channel
names?
GRANT LISTEN, NOTIFY ON CHANNEL * TO PUBLIC; -- enabled by default for
backwards compat
NOTIFY xxxx; -- OK via * CHANNEL
LISTEN xxxx; -- OK via * CHANNEL
Chris
On 18 June 2013 18:31, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
> >> I had a quick play to see what might be involved [attached], and would
> like to
> >> hear people thoughts; good idea, bad idea, not like that! etc
> >
> > I question the usefulness of allowing listen/notify to be restricted to
> > an entire class of users. The granularity of this seems too broad,
> > though I am not sure if allowing message to be sent to a specific user
> > is easily achievable.
>
> Well, if we're going to have privs on LISTEN/NOTIFY at all, they should
> be on specific message bands, i.e.:
>
> REVOKE LISTEN ON 'cacheupdates' FROM PUBLIC;
> GRANT LISTEN ON 'cacheupdates' TO webuser;
> GRANT LISTEN ON ALL TO admin;
>
> I can certainly see wanting this, but it'd be a great deal more
> sophisticated than what Chris has proposed.
>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-06-27 09:49:47 | Re: in-catalog Extension Scripts and Control parameters (templates?) |
Previous Message | Ants Aasma | 2013-06-27 09:45:53 | Re: Hash partitioning. |