Icecast - May 2017 - Circumvention of authentication when using fallback mounts

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.

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.

> 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?
This would definitely help, yes, and I would appreciate if you could
create the ticket in your system.
> I hope that this mail was at least helpful by confirming the problem.
Yes, it was.

Thank you,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20170513/e245c6c0/attachment.sig>

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>

On 05/13/2017 09:46 PM, Philipp Schafft wrote:
> I think this is something totally unrelated.
Yes, my thought on the authentication was unrelated, and not relevant to
the subject. Thanks for your hints regarding the POST API.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20170515/a1a34a32/attachment.sig>