135 replies to this topic

[anudanan]

Very interesting to read all these statements. Thanks for the interesting discussion. I´m looking forward what will happen in the future around the streaming features

[anudanan]

The changes needed for the session cookie will probably mean, one way or another, that the solution I had for for anudanan's case can probably no longer be supported. Anyway I think the combination of OWIF auth disabled and streaming auth enabled is a jar full of snakes and something you'd really not should be wanting (even if the use of a certain app dictates it).

 

That was not me really request.

 

My first request was to use the OWIF.auth_for_streaming instead OWIF.auth parameter in streamproxy to make the possibility to use OWIF with auth but no auth with streaming: I´ve no need for OWIF without auth and streaming with auth. That is what the new streamproxy now do and that works fine. IF the streaming with auth is enabled it works also fine.

[Erik Slagter]

Your saying here exactly the same?

 

Anyway, all these configurations:

- auth on enigma2 streamserver

- auth in the streamproxy config

- auth in the OWIF config, either OWIF access or streaming

 

seem to be independent but actually they're not. It's complex matter.

 

And as said, if we want to remain fully compatible with OWIF (especially the session cookie), this very well may have to go. Maybe not. We'll see.

Edited by Erik Slagter, 10 January 2019 - 20:23.

[anudanan]

We will see what the future brings up ;-)

[SpaceRat]

The changes needed for the session cookie will probably mean, one way or another, that the solution I had for for anudanan's case can probably no longer be supported. Anyway I think the combination of OWIF auth disabled and streaming auth enabled is a jar full of snakes and something you'd really not should be wanting (even if the use of a certain app dictates it).

That was not me really request.

My first request was to use the OWIF.auth_for_streaming instead OWIF.auth parameter in streamproxy to make the possibility to use OWIF with auth but no auth with streaming: I´ve no need for OWIF without auth and streaming with auth. That is what the new streamproxy now do and that works fine. IF the streaming with auth is enabled it works also fine.

"Auth for streaming" inside OWIF does not affect auth for OWIF itself.
In fact, it doesn't even affect live streaming in OpenPLi at all (well, negatively it does).

Though Erik is again trying hard to be an ***hole, he is correct in some places:
Having auth in OWIF disabled but enabled for streaming is a somewhat strange use case and it's the only scenario in which we require transient logins.

If you enable auth for OWIF itself, it will use the cached credentials from login for the streaming URLs it creates instead of transient logins. These credentials work with all variants of streaming.

Gesendet von meinem SM-N950F mit Tapatalk

[WanWizard]

Please keep your tone in check.

 

The fact someone doesn't understand part of the discussion, doesn't understand how certain hacks or code changes for specific (non-OpenPLi) platforms work, or trying to get a complete overview of use-cases and current implementations doesn't make them anything close to the word you are using.

 

Likewise, as soon as someone tries to have a discussion with you and it is not going the way you want, your behaviour isn't entirely clean as well. But I don't call you an ***hole.

 

Bottom line is that there are flaws in the design, which require structual changes that benefit us all, so it is beneficiary for all of us to remain positive, solve it together, and have an understanding for the position of others in the discussion.

[anudanan]

@spacerat

 

Are your sure with the credentials? I´ve made many tests in the last days and I have use OWIF with auth and also with auth for streaming and exactly then  all m3u8 downloads for streaming (direct or transcoded) includes the transient -sid logins in the URL instead of the cached login credentials

 

I think OWIF always use -sid credentials if auth for streaming is enable

Edited by anudanan, 10 January 2019 - 21:31.

[anudanan]

Now I have found out how OWIF uses the login credentials also for streaming auth and put them into the m3u8 file.

 

the user must bei in /etc/passwd but with the /bin/false instead of /bin/sh. If you goto OWIF with those no shell users then the m3u8 include that user/pw instead of -sid transient login

 

Very tricky and I haven´t know that before now. But know I have learned that. 

[anudanan]

From my point of view the new streamproxy works better than in the past with the different combinations of the OWIF Auth parameter for OWIF access and streaming accecc especially with some APPs but also with a brower. 

 

I think it would bei great iif you take the new one into the 7.0 branch for rc and release.

 

That make many users happy which habe trouble with authentication and streamings APPs..

 

 

Nevertheless the installation of a non shell user in passwd (not root) is a next good idea to use auth for both (OWIF and streaming), But I think that also works in the past because, but the most users don´t know these feature and the handling ot install a user without shell (/bin/false)

[Erik Slagter]

Your use case is very small against what most user do. I can not guarantee that we will go out of our lengths to keep it working. I have some ideas now and your use case may not fit in it.

[SpaceRat]

the user must bei in /etc/passwd but with the /bin/false instead of /bin/sh.

First part is enough: The user must be in /etc/passwd with a valid pass.
The shell doesn't matter, though having a user without a valid shell (For ssh and telnet) and no valid home (For FTP) slightly increases security.

If you goto OWIF with those no shell users then the m3u8 include that user/pw instead of -sid transient login

Correct. After successful auth, OWIF caches the credentials it got and uses them for any spanning (leaving OWIF) URLs it has to create.

Transient logins are only used if auth for OWIF is disabled (That means: OWIF doesn't even see any credentials at all that it could cache) and auth for streaming in OWIF is enabled.

[WanWizard]

Transient logins are only used if auth for OWIF is disabled (That means: OWIF doesn't even see any credentials at all that it could cache) and auth for streaming in OWIF is enabled.

 

Any particular reason why? As that would mean exposing real credentials in the m3u8 file, which in turn means enabling auth for OWIF actually reduces security? I think caching credentials is from a security standpoint very bad practice...

 

Why not always use the transient login?

[anudanan]

 

the user must bei in /etc/passwd but with the /bin/false instead of /bin/sh.

First part is enough: The user must be in /etc/passwd with a valid pass.
The shell doesn't matter, though having a user without a valid shell (For ssh and telnet) and no valid home (For FTP) slightly increases security.

 

 

This is not true on my Box with OWIF auth enabled and streaming auth enabled.

I´ve tested it now but the -sid login is in the m3u8 file, if the user has not /bin/false as a shell but the normal /bin/sh shell. Only with /bin/false as a shell the m3u8 contain the user/pw credentials.

[SpaceRat]

Why not always use the transient login?

E.g. because they don't work in OpenPLi? 

They don't work in a default installation of OpenATV, OpenViX or whatever either, only after one performs some additional step.

 

And the m3u only reveals credentials you just entered anyways ... and OWIF has an option to deny access to the root user, so the credentials can be those of a user who doesn't even get shell access.

 

Within the given limits that was the best possible solution from the pool of ugly solutions.

[anudanan]

The reason for the need off /bin/false noshell user to avoid -sid login from my point of view are the codeline in httpserver.c 

            session["logged"] = True
            session["user"] = request.getUser()
            session["pwd"] = None
            if self.noShell(request):
                session["pwd"] = request.getPassword()
            return self.resource.getChildWithDefault(path, request)

and in controllers/models/stream.py

    def GetAuth(self, request):
        session = request.getSession().sessionNamespaces
        if "pwd" in session.keys() and session["pwd"] is not None:
            return (session["user"], session["pwd"])
        else:
            return None

Edited by anudanan, 11 January 2019 - 12:06.

[SpaceRat]

This is not true on my Box with OWIF auth enabled and streaming auth enabled.
I´ve tested it now but the -sid login is in the m3u8 file, if the user has not /bin/false as a shell but the normal /bin/sh shell. Only with /bin/false as a shell the m3u8 contain the user/pw credentials.

I stand corrected, according to
https://github.com/E...er.py#L274-L281
and
https://github.com/E...er.py#L366-L367
you are correct.

Caching credentials only happens if a non-shell user is used.

[WanWizard]

 

Why not always use the transient login?

 

E.g. because they don't work in OpenPLi? 

 

I know that.

 

But problems should be fixed at the root cause point, not worked around elsewhere. 

 

The non-working "-sid" user is our problem, and I'm already looking into that.

[WanWizard]

Caching credentials only happens if a non-shell user is used.

 

Ah, ok. I can live with that.

[SpaceRat]

I used to have these commands at the end of myrestore.sh (A script that gets invoked on OpenATV after successful flash with settings restore):

adduser webif -h /dev/null -s /bin/false -H -D
echo -e "webifpass\nwebifpass\n" | passwd webif >/dev/null
echo -e "rootpass\nrootpass\n" | passwd >/dev/null

That way I always have some unprivileged user for web access (and a password for the root user).

"Used to", because in the meantime OpenATV restores users itself on settings restore, so they don't get lost on flash anymore.

[WanWizard]

The OpenPLi restore has always restored additions to /etc/passwd, /etc/group and /etc/shadow automatically.