[Icecast] Circumvention of authentication when using fallback mounts

[Philipp Schafft]

Good evening,

On Sat, 2017-05-13 at 16:11 +0200, Michael Franzl wrote:
> On 05/13/2017 03:12 PM, Philipp Schafft wrote:
> > 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.
> 
> Sounds about right. Here is another unexpected but similar scenario,
> which is the current behavior of Icecast:
> 
> If /music is a declared fallback stream of /voice, and a client connects
> directly to /music, then, when /voice comes online, the client is be
> moved to /voice, even though the client has never requested to hear voice.
> 
> I think the simplest solution would be when Icecast, for each client,
> constructs a chain (a simple 1D array) of mounts he has 'fallen though',
> and then, when any parent mount of this chain comes online, moves the
> client up to that parent, but no further than that. If a client is moved
> back up the chain, all 'lower' parts of that chain can be forgotten.

That is basically what I thought about. That stack I talked of is
basically that 1D array plus a pointer to the current entry ('bottom
most' one).


> Regarding authentication in this scenario, Icecast should not
> remember/cache any previous authentications. As soon as a client is
> moved to *any* mount (caused by falling through or moving back), it
> should do a fresh authentication request. For example, permission to
> listen to a stream could have been revoked from the time a client first
> connects, then falls through to a fallback, to the time when he is moved
> back to a private stream.

I think this is something totally unrelated.
Also I think as fallbacks are configured by the admin a client is
implicitly considered authenticated ('admin said so in config').
Furthermore re-authing is something that has a lot problematic bad-paths
and would likely be unstable on larger setups. (technical note: Icecast
does not cache any kind of authentication data. It only keeps track of
what is needed to emit a remove event.)

Revoking permissions is yet another concept. You can already do that
perfectly fine with current Icecast2: part of the POSTed parameters in
the URL Auth request is a parameter 'client'. That value can be used to
kick the listener using an /admin/killclient*?mount=$MOUNT&id=$CLIENTID
(since at least Icecast2 2.3.x) request at any time. This way you can
remove a client the moment the permission is revoked with virtually no
delay.



> > Would a update for 2.5.x help you?
> 
> This would definitely help, yes, and I would appreciate if you could
> create the ticket in your system.

Will do the next time I look into the system.


> > I hope that this mail was at least helpful by confirming the problem.
> 
> Yes, it was.

Good. :) Also hope my comment on the revoking and removal helps.

Wish you a good weekend. I will be back on Monday.

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/078adb66/attachment.sig>