[Icecast] Circumvention of authentication when using fallback mounts

[Philipp Schafft]

Good afternoon,


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:
> 
> /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.

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
decides otherwise).

Would a update for 2.5.x help you?

If you need a backport for 2.4.x you might consider contacting me
off-list.

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:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170513/3a96d80f/attachment.sig>