Project

General

Profile

Bug #3440

TVHeadEnd needs implicit rule to allow access from 127.0.0.1 (or "localhost")

Added by K Shea almost 9 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Configuration
Target version:
-
Start date:
2015-12-26
Due date:
% Done:

0%

Estimated time:
Found in version:
HTS Tvheadend 4.0.8
Affected Versions:

Description

Since apparently people got bogged down in the details I provided in my previous report, let me try restating the problem without going into too much detail.

If you create a rule in Access Entries - Network prefix (allowed networks in 4.1) and your rule does not include 127.0.0.1 then TVHeadEnd cannot be accessed from the machine it is running on. In theory you could (with a simple typo) create a situation where TVHeadEnd is inaccessible from its own machine or from any other system on the network. The specific bug is that TVHeadEnd should implicitly allow full access from the machine it is running on, regardless of what else is in the Network prefix/allowed networks field.

A secondary issue is that the help screen does not show the correct syntax to specify two different addresses or address ranges in that field, so we are left to guess how that should be done or whether it's even possible. And doing it wrong could lock you out of the system, so it's not something you want to guess at.

History

#1

Updated by Jaroslav Kysela almost 9 years ago

1) Could you show me another application with the default 127.0.0.1 rule ?

2) I see in help this: "Network prefix : IPv4 prefix for matching based on source IP address. If set to 0.0.0.0/0 it will match everything. The multiple networks can be delimited using comma or semicolon." . You may give a better text here: https://github.com/tvheadend/tvheadend-documentation/blob/master/docs/webui/config_access.md , create PR there

#2

Updated by K Shea almost 9 years ago

1) No but there are few other pieces of software where you would both have access controls in the first place AND where there might be a reason that you'd want the program to be able to access its own output (as in this case where it's using the pipe:// syntax to run a received stream through ffmpeg in real time and present the output as a channel).

2) I apologize, I do not know how I missed that, unless it was that I was so confused by the "Network prefix" designation to begin with. Anyway, based on that I tried using 192.168.10.0/24,127.0.0.1/32 and it appears to be working (TVHeadEnd actually added the /32, I did not type that). I still don't know what is meant by "create PR", I am not a developer or coder and I know nothing about Github except that it's a software repository. However the way I would have stated so that users not quite as familiar with networking could understand it is this:

Network prefix/Allowed networks : IPv4 address ranges, which are matched based on the IP address of the connected device. If set to 0.0.0.0/0 it will match everything and allow a connection from anywhere. Multiple address ranges can be specified using a comma or semicolon as a separator between the address ranges. A single IP address can also be specified (TVHeadEnd will automatically add the /32 range suffix if not specified). If TVHeadeEnd needs to be able to access itself for some reason, include 127.0.0.1/32 in the list of allowed address ranges.

Thank you for clarifying this, and again I apologize for not seeing that text in the first place.

#3

Updated by Wild Penguin over 8 years ago

Just wanted to comment, that I needed to add ::1 into the list, to be able to contact to "localhost:9981" from a browser (127.0.0.1/32 was not enough). It seems my current distribution enables ipv6 in local network, and uses ipv6 resolving per default. Maybe ::1 could be added as an example of localhost to the help text. I suggest following wording: "If you want this user to be able to access tvheadend from the local host, add ::1 and/or 127.0.0.1 to the list."

I propose adding a simple checkbox "allow this user to connect from local host" which will enable access (from 127.0.0.1 and ::1) for user friendliness (but I can also see the rationale of not putting in such a checkbox - it will keep the interface leaner).

Also available in: Atom PDF