[Icecast] Circumvention of authentication when using fallback mounts
phschafft at de.loewenfelsen.net
Sat May 13 13:12:30 UTC 2017
On Fri, 2017-05-12 at 14:37 +0200, Michael Franzl wrote:
> Using latest icecast, let's assume the following hosting scenario.
(For the records: this applies to 2.4.x as well as current 2.5.x.)
> We have 2 mountpoints which are configured with authentication callbacks:
> Both mountpoints have configured the same fallback stream, mounted at
> '/fallback'. Both have fallback-override enabled, so they both can move
> listeners back from the fallback when they come online.
> Suppose that both mounts are currently not mounted. Now a client is
> connecting and successfully authenticating with mountpoint /mount1.
> Because /mount1 is not yet available, he is moved to /fallback.
> Now suppose /mount2 comes online. The client is now moved from /fallback
> to /mount2, even though he has never authenticated with /mount2, but
> only with /mount1. In fact, the client has no permission at all to
> connect to /mount2.
> In short, authentication can be circumvented if the same fallback stream
> is configured for two 'authenticatable' streams.
> This would not be a problem if we only used two mounts. We could simply
> configure two separate fallbacks.
Basically Icecast moves back the listeners without checking which mount
they came from.
> But suppose now that we use a wildcard to configure not just two, but N
> private mounts, i.e. /mount*, so that the mount name is fully determined
> by the source client. In this scenario, we cannot use a common fallback
> mount any more without possible circumvention of authentication.
> Latter scenario is useful when the N mounts carry private audio, and
> fall back to one stream of 'fallback' music.
Yes. It also applies in case you have manual configuration for multiple
mount sharing the same fallback.
> Is there any way to make this scenario work?
Not as of now (beside a lot of fallbacks).
A bit of a technical sidenote:
Basically the client structure would need to keep track of which sources
the client was attached to in form of a stack. This is important as
there can be fallbacks of fallbacks (and there are valid reasons to
build something like that). A pure 'original mount' thing may result in
unexpected behavior. That being even more true if there are multiple
paths from one mount to another.
Speaking of a solution:
I think this is a very valid request for 2.5.x. I would open a ticket
for it if you don't want to do it yourself. But 2.5.x is still beta. On
the other side 2.4.x will only updated with (security or regression)
fixes. So I don't see it entering 2.4.x (unless tbr, our Project Manager
Would a update for 2.5.x help you?
If you need a backport for 2.4.x you might consider contacting me
I hope that this mail was at least helpful by confirming the problem.
Wish you a good weekend,
with best regards,
Philipp Schafft (CEO/Geschäftsführer)
Telephon: +49.3535 490 17 92
Löwenfelsen UG (haftungsbeschränkt) Registration number:
Bickinger Straße 21 HRB 12308 CB
04916 Herzberg (Elster) VATIN/USt-ID:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: This is a digitally signed message part
More information about the Icecast