Thread: LISTEN filtering
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Quick idea to toss out there: allowing an option to LISTEN to only 'hear' from superusers (or self). I've got an app that uses a lot of listen/notify to talk to other subprocesses. However, it would be nice if non-superusers could not affect the behavior of this application: right now, anyone can issue a NOTIFY. (Yes, I can look information up about the calling notifier's PID, but that's not easy). Rather than a full 'rights' system (which would be complex overkill), what if we had an option to LISTEN that said "I only want to hear notices coming from superusers"? Or perhaps an option that says "I only want to hear notices coming from me (same role)"? This would not affect notifications at all, but would simply act as a quick filter on incoming notices for a specific listener. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201106211156 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk4Av1UACgkQvJuQZxSWSsgMKACgoM8de4sD0Hya0We2ncxmbsNE eU0AnjWh8Iqhu8cGMaywGhtxs4rQ7HOh =M7Ms -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Quick idea to toss out there: allowing an option to LISTEN to
> only 'hear' from superusers (or self).
This seems like a pretty bad idea from a security policy standpoint,
in that it would encourage use of superuser state to run ordinary
applications.
> I've got an app that uses a lot
> of listen/notify to talk to other subprocesses. However, it
> would be nice if non-superusers could not affect the behavior
> of this application: right now, anyone can issue a NOTIFY.
Anyone connected to the same database, yes. Can't you just restrict use
of the database to trustworthy apps?
regards, tom lane
On Tue, Jun 21, 2011 at 10:58 AM, Greg Sabino Mullane <greg@turnstep.com> wrote: > Quick idea to toss out there: allowing an option to LISTEN to > only 'hear' from superusers (or self). I've got an app that uses a lot > of listen/notify to talk to other subprocesses. However, it > would be nice if non-superusers could not affect the behavior > of this application: right now, anyone can issue a NOTIFY. (Yes, > I can look information up about the calling notifier's PID, > but that's not easy). Rather than a full 'rights' system (which > would be complex overkill), what if we had an option to LISTEN > that said "I only want to hear notices coming from superusers"? > Or perhaps an option that says "I only want to hear notices > coming from me (same role)"? This would not affect notifications > at all, but would simply act as a quick filter on incoming > notices for a specific listener. hm. maybe you could use the 9.1 payload feature so that your custom behavior would only be invoked if a particular payload was sent? merlin
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Tom wrote: > This seems like a pretty bad idea from a security policy standpoint, > in that it would encourage use of superuser state to run ordinary > applications. Yeah, I think the "only from same user" is much better in retrospect. > Anyone connected to the same database, yes. Can't you just restrict use > of the database to trustworthy apps? In this case, no, as I only want to limit /some/ notifications. In other words, listen/notify has both a public and private usage. Merlin asked: > hm. maybe you could use the 9.1 payload feature so that your custom > behavior would only be invoked if a particular payload was sent? Interesting idea! I could go even further and just use randomly generated listen names, rather than worrying about the payload, as the listen/notify names are no longer exposed to anyone else. Thanks, I think that neatly solved the problem. (which wasn't too much of a problem, more an idle thought). - -- Greg Sabino Mullane greg@endpoint.com greg@turnstep.com End Point Corporation 610-983-9073 PGP Key: 0x14964AC8 201106212307 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk4BXLcACgkQvJuQZxSWSsgVPACdG8QhZqFKTpS8e+QMO/abIhgl ts4AnRZQGveWfr82sOq6CuGZnzwG3RnX =7XmU -----END PGP SIGNATURE-----