[Icecast] Circumvention of authentication when using fallback mounts
office at michaelfranzl.com
Fri May 12 12:37:36 UTC 2017
Using latest icecast, let's assume the following hosting scenario.
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.
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.
Is there any way to make this scenario work?
More information about the Icecast