[Icecast] Circumvention of authentication when using fallback mounts
Michael Franzl
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:
/mount1
/mount2
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?
Thanks,
Michael
More information about the Icecast
mailing list