Currently, pulse has a 'public' user, with a password that's available publicly (e.g., http://hg.mozilla.org/users/clegnitto_mozilla.com/mozillapulse/file/2a1719df73a3/mozillapulse/config.py#l9), and this is used by default in the mozillapulse lib. This user has full read/write access to pulse, so it would be easy for an attacker to use this to publish garbage messages into pulse until it fell over. We should, in the very near term: 1 - change 'public' to have read-only access 2 - provide specific accounts to people who want to publish to pulse (currently only buildbot and seabld use non-public accounts for this) In pulse's current state, it's also possible to bring pulse down with read-only access: someone could setup a bunch of durable queues and not consume anything from them. This would eventually cause pulse to run out of memory and die. If enough queues were created, this wouldn't take too long. We should figure out how to prevent this, whether it requires auth for read access, or implementing some kind of intelligent queue monitoring.
Adding cc's of people that I know have built tools on pulse so that they can be informed as we make a breaking change here to address this issue.
so my rough gut feeling there is to auto-expire "public" messages when not consumed after [x]. And have a slightly longer default expiry for private accounts, if there is a need. and if there is a great need and decent auditing we can have an even longer auto-expire for other users of pulse, with a specific login.
We don't have any pulse-based tooling on the l10n side at this point. For doodling around with consumers, read-only and non-durable (or only slightly) is probably fine. It'd be nice to have a proposed path on how to hack on producers at some point, too.
(In reply to Justin Wood (:Callek) from comment #2) > so my rough gut feeling there is to auto-expire "public" messages when not > consumed after [x]. And have a slightly longer default expiry for private > accounts, if there is a need. > and if there is a great need and decent auditing we can have an even longer > auto-expire for other users of pulse, with a specific login. RabbitMQ doesn't provide a way to do this by default. It does support expiration of messages and queues, but it's up to the creator of the queue to declare that; RabbitMQ doesn't allow you to specify global or per-user expiration periods.
(In reply to Jonathan Griffin (:jgriffin) from comment #4) > (In reply to Justin Wood (:Callek) from comment #2) > RabbitMQ doesn't provide a way to do this by default. It does support > expiration of messages and queues, but it's up to the creator of the queue > to declare that; RabbitMQ doesn't allow you to specify global or per-user > expiration periods. "Just because the tool we use now doesn't support the good solution, doesn't mean there isn't another better tool, or that we can't modify one tool to be actually useful" ;-)
Didn't mean to grab this out from under the actual owner :) jgriffin, do you have an idea of when this might be fixed?
Assignee: laura → jgriffin
I don't; I'm not actively working on it. To fix this, we'll have to get IT to enable SSL on pulse, then migrate current users to domain-specific vhosts that require authentication.
(In reply to Jonathan Griffin (:jgriffin) from comment #7) > I don't; I'm not actively working on it. To fix this, we'll have to get IT > to enable SSL on pulse, then migrate current users to domain-specific vhosts > that require authentication. I am actually on the hook to get this cleaned up but due to some other goals taking way too long I wasn't really able to get much progress this quarter. It will be my goal for the coming quarter once more to get SSL and separate vhosts configured properly on our current environment. I feel like this is something definitely important to do but will take some time as it will need to be properly communicated in advance. dkl
We are fixing this through a combination of PulseGuardian and tighter permissions.
Depends on: 1015037
The public user has been deleted, and PulseGuardian is monitoring queues and deleting them when they become too large.
Group: mozilla-employee-confidential, webtools-security
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.