[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:


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 mailing list