693 replies to this topic

[Erik Slagter]

Streamproxy must do it's own authentication because openwebif doesn't offer access from selected uid's (from a certain gid). I wouldn't my "root" user to be exposed to internet...

[SpaceRat]

Streamproxy must do it's own authentication because openwebif doesn't offer access from selected uid's (from a certain gid). I wouldn't my "root" user to be exposed to internet...

root@ultimo:~# adduser test -h /dev/null -s /bin/false -G users -H
Changing password for test
New password: Blah
Retype password: Blah
Password for test changed by root

After that, I can login to the webif as user "test" with password "Blah".

If the impossibility to disable root logins is your only problem with a clean solution for streaming .... I can add that.

[Erik Slagter]

No that is not what I want. I want only certain users to be able to do streaming. I don't care about the actual streaming, but leaving all users enabled for streaming (and also webif, but I am not going to expose that anyway), means anyone can probe passwords. If only one, non-priviledged user is granted access, then the highest risk is that this password is guessed (c.q. brute force determined). That's at least a tiny bit less unpreferable than an exposed root password.

[SpaceRat]

No that is not what I want. I want only certain users to be able to do streaming. I don't care about the actual streaming, but leaving all users enabled for streaming (and also webif, but I am not going to expose that anyway), means anyone can probe passwords. If only one, non-priviledged user is granted access, then the highest risk is that this password is guessed (c.q. brute force determined). That's at least a tiny bit less unpreferable than an exposed root password.

So what I said is exactly what you want:
1. By adding a user w/o home and just /bin/false as shell, the only credentials that can be sniffed are that of a worthless restricted user account.
2. When at the same time the OpenWebif disallows the root user (or even the whole root group), it can't even be used for probing the root password anymore (Because even with the correct credentials for root, login would fail).

I was thinking about this anyways (Though there are more users that complain about a password popup or the need to change one than about their box being open to everybody and his grandma ...).

Edited by SpaceRat, 15 May 2014 - 16:25.

[Erik Slagter]

pieterg has just pushed a commit that makes the internal streamserver (port 8001, streaming-no-transcoding), for authentication, configurable, indepedent of the open web interface, because it has no relation with the open web interface.

 

This means, from tomorrow on, that if you want authentication on plain streaming, you should set the option "Require authentication for http streams" inside the enigma settings for streaming (it's between the other streaming options, like "Descramble http streams" etc.

commit 5d6c607bf2f2c3feb7d5213be57a65ac539e8b4a
Author: pieterg <pieterg@users.sourceforge.net>
Date:   Thu May 15 17:40:36 2014 +0200
    streamserver: use internal setting for authentication
   
    the streamserver should not depend on the webinterface,
    so introduce our own setting, instead of checking an
    external openwebif setting.

[SpaceRat]

Not really user-friendly (Yet another setting) but it's actually clean.

Does the internal streamproxy now listen on :: or still on 0.0.0.0 only?
Can the port be changed?

Those would be features that bring us forward ...

[Erik Slagter]

I guess you can look at the patch yourself

[SpaceRat]

I guess you can look at the patch yourself

If you would have linked it

Those commits are not as easy to google as you might believe, especially not right after they were committed ...
And no, I don't know each and every git/svn whatever repo's address by heart nor do I have bookmarked them all

[Erik Slagter]

git://git.code.sf.net/p/openpli/enigma2

commit 5d6c607bf2f2c3feb7d5213be57a65ac539e8b4a
Author: pieterg <pieterg@users.sourceforge.net>
Date:   Thu May 15 17:40:36 2014 +0200
    streamserver: use internal setting for authentication
   
    the streamserver should not depend on the webinterface,
    so introduce our own setting, instead of checking an
    external openwebif setting.
diff --git a/data/setup.xml b/data/setup.xml
index 3b89327..1ec5cf6 100644
--- a/data/setup.xml
+++ b/data/setup.xml
@@ -19,6 +19,7 @@
   <item level="2" text="Include AIT in http streams" description="When enabled, AIT data will be included in http streams. This allows a client receiver to use HbbTV.">config.streaming.stream_ait</item>
   <item level="2" text="Include ECM in http streams" description="When enabled, ECM data will be included in http streams. This allows a client receiver to do the descrambling.">config.streaming.stream_ecm</item>
   <item level="2" text="Descramble http streams" description="When enabled, http streams are descrambled on the server side. The (remote) client receiver does not have to do descrambling.">config.streaming.descramble</item>
+  <item level="2" text="Require authentication for http streams" description="When enabled, authentication is required to watch http streams.">config.streaming.authentication</item>
   <item level="2" text="Fan operation" description="Configure how the fan should operate" requires="Fan">config.usage.fan</item>
   <item level="2" text="Fan speed" description="Configure the speed of the fan" requires="FanPWM">config.usage.fanspeed</item>
   <item level="2" text="Startup to Standby" description="Startup the set top box in standby">config.usage.startup_to_standby</item>
diff --git a/lib/dvb/streamserver.cpp b/lib/dvb/streamserver.cpp
index 8b16382..fa3c6fb 100644
--- a/lib/dvb/streamserver.cpp
+++ b/lib/dvb/streamserver.cpp
@@ -55,7 +55,7 @@ void eStreamClient::notifier(int what)
     if (request.substr(0, 5) == "GET /")
     {
      size_t pos;
-     if (eConfigManager::getConfigBoolValue("config.OpenWebif.auth_for_streaming"))
+     if (eConfigManager::getConfigBoolValue("config.streaming.authentication"))
      {
       bool authenticated = false;
       if ((pos = request.find("Authorization: Basic ")) != std::string::npos)
diff --git a/lib/python/Components/UsageConfig.py b/lib/python/Components/UsageConfig.py
index 9072b1b..99b9973 100644
--- a/lib/python/Components/UsageConfig.py
+++ b/lib/python/Components/UsageConfig.py
@@ -492,6 +492,7 @@ def InitUsageConfig():
  config.streaming.descramble = ConfigYesNo(default = True)
  config.streaming.stream_eit = ConfigYesNo(default = True)
  config.streaming.stream_ait = ConfigYesNo(default = True)
+ config.streaming.authentication = ConfigYesNo(default = False)

def updateChoices(sel, choices):
  if choices:

[SpaceRat]

commit 5d6c607bf2f2c3feb7d5213be57a65ac539e8b4a
would have been sufficient, but thanks

Well, sadly
- port 8001 is hardcoded
- lib/network/serversocket.cpp remained unchanged = IPv4-only

One step forward (Auth no longer broken), two steps back (the external streamproxy could be made listening on dual stack sockets via inetd; yet another option to set up).

[Erik Slagter]

Don't shoot the messenger.

 

Although I agree with pieterg and disagree with you. Bummer...

[SpaceRat]

@Erik:

If you would be so kind to rename your transcoding proxy binary to transproxy or whatever, I could modify OpenWebif to toggle the E2 setting for internal streaming if internal streaming is used.

You have to agree that using a name for a binary which has previously existed on the same system before but did something else is not really clean.
It makes checks for that file break and in addition OpenWebif can neither detect your transcoding proxy like it can detect the transcoding plugin of other images.


The point is, I could simply do this:

if not fileExists('/usr/bin/streamproxy'):
   self.list.append(getConfigListEntry(_("Enable Authentication for streaming"), config.streaming.authentication))
else:
   self.list.append(getConfigListEntry(_("Enable Authentication for streaming"), config.OpenWebif.auth_for_streaming))

to avoid a confusing mismatch of the stream auth setting and the actual behaviour ...
But only if /usr/bin/streamproxy can ONLY be the original streamproxy again (Which is still used in many images).

On the other side, one could do a check for /usr/bin/transproxy to see if the Erik Slagter transcoding is available, which can not be done using a check for /usr/bin/streamproxy because that could as well be tthe original stream proxy ...
A check for /etc/enigma2/streamproxy.conf wouldn't serve the same purpose, config files re-appear or remain under many circumstances ....

[Erik Slagter]

the external streamproxy could be made listening on dual stack sockets via inetd

The external streamproxy already IS listening dual stack, it has been since the start. I don't know what you're talking about.

 

Also inetd is "suboptimal" (a.o. on resources) I will never make a serious program that uses inetd, especially not the braindead version from busybox. Inetd is suitable for q&d scripts, not for real services.

[Erik Slagter]

If you would be so kind to rename your transcoding proxy binary to transproxy or whatever, I could modify OpenWebif to toggle the E2 setting for internal streaming if internal streaming is used.

I am considering that, not for the sake of the webif, but simply because it's a poorly choosen name in retrospective.

 

It makes checks for that file break and in addition OpenWebif can neither detect your transcoding proxy like it can detect the transcoding plugin of other images.

Any webif should never need to adjust for the streamproxy. Not a good idea.

 

if not fileExists('/usr/bin/streamproxy'):
   self.list.append(getConfigListEntry(_("Enable Authentication for streaming"), config.streaming.authentication))
else:
   self.list.append(getConfigListEntry(_("Enable Authentication for streaming"), config.OpenWebif.auth_for_streaming))

Ieeeeeeek. Not going to happen.

Edited by Erik Slagter, 15 May 2014 - 18:35.

[SpaceRat]

Don't shoot the messenger.

I didn't shot anyone.

I'm just disappointed that ages of work (one month or so?) have no other result as the proper behaviour as we already had from 2007 to 2011 (and in other images til now).
 

Although I agree with pieterg and disagree with you. Bummer...

Well, the way we can now achieve almost the same as before is ok now.

However, my expectation when I start to work on something is not to just get it working just like before but at least a bit better.

If getting rid of a 9k binary is enough success to you ... well ...

[SpaceRat]

The external streamproxy already IS listening dual stack, it has been since the start.

The external streamproxy was removed in 2011 by pieterg.

I don't know what you're talking about.

You would if you haven't given your transproxy the same file name *vbeg*

[WanWizard]

The problem in this discussion is that you think the old and crap solution, invented in DMM days with an old webif and no transcoding in sight, is the correct and proper solution.

But it isn't. It is a complete spaghetti mess, hacked in over the years in an attempt to maintain BC yet introduce new features.

 

We have no interest whatsoever in supporting the old Webif, that thing is dead and burried, and only works on genuine DMM equipment, which we don't even support anymore.

 

It we have to stick to old crap once created in a distant past, there will never be any innovation.

[SpaceRat]

It makes checks for that file break and in addition OpenWebif can neither detect your transcoding proxy like it can detect the transcoding plugin of other images.

Any webif should never need to adjust for the streamproxy. Not a good idea.

Meep.
It needs to.

Currently transcoding depends on transproxy listening on port 8002 for live TV and port 8003 for recordings.

Why?

Simply because the Webif doesn't and can't know better.
As soon as the user changes the port(s) in /etc/enigma2/streamproxy.conf , it would stop to work.

Also, one of the benefits of your variant of transcoding is, that it can do both, live TV and recordings, on the same port using parameters.
Without the webif knowing your transcoding is used, it can not adjust to this, i.e. create URLs with parameters but using the same port for both ...

So the only reason why transcoding via Webif currently works at all in OpenPLi 4.0 is transproxy being pre-configured in a way compatible to Vu+'s defaults.

Thus ...
OpenWebif needs to know if it has to use Vu+'s transcoding or yours or none at all.

Edited by SpaceRat, 15 May 2014 - 18:55.

[Erik Slagter]

Try this: http://stb:8002/ or http://stb:8002/web?request=info or http://stb:8002/web?...est=info&xml=1.

[SpaceRat]

The problem in this discussion is that you think the old and crap solution, invented in DMM days with an old webif and no transcoding in sight, is the correct and proper solution.
But it isn't. It is a complete spaghetti mess, hacked in over the years in an attempt to maintain BC yet introduce new features.

Even the worst solution is still better than the best problem.

I do not even have the slightest problem with the removal of the streamproxy ...
As long as it is done with brains on and not just "Huh? What's this file for? F*ck it, just delete it ...".

Actually, if I had to decide, even more external stuff was removed and instead done inside E2, because Python-Plugins can never achieve the same as clean C++ code inside the main code.

But:
When pieterg removed the streamproxy in 2011, he did NOT check what it is used for but simply deleted it. He did NOT look into the code and wondered why it contains "Basic Auth" bla while E2's code didn't.
The OE-A devs obviously noted the accidential removal of auth support much earlier, because in their fork of OpenWebif they commented out the stream auth option (Because it simply didn't work anymore ...) ages ago ...

If pieterg would have made todays commit 5d6c607bf2f2c3feb7d5213be57a65ac539e8b4a back in 2011, right after or better right before removing streamproxy, nobody would have complained.

It we have to stick to old crap once created in a distant past, there will never be any innovation.

That's exactly my point.

And that's why I always said that wedding E2 to a specific plugin is a bad idea.
As we have now prevented this big step back, someone might look into real steps forward (IPv6-support for the internal streaming, configurable port(s) for streaming, IPv6-support for the stream client) ...

And after those tiny steps forward, one could look at some real progress:

Plugins should hook where they really belong to, e.g. CrossEPG, CoolTVEPG Setup, XMLTV Importer, EPG Refresh and so on under "Settings -> EPG", "Youtube", "YouPorn", "Facebook" and so on under "Online Services" or something like that, a.s.o. a.s.o., rather than collecting all plugins regardless of what they do under "Plugins".

Actually, EPG Refresh shouldn't be a plugin at all, even my TV set has this functionality built in.

...