[ANNOUNCE] vdr-restfulapi 0.1.0

Moin!

Da die Kommunikation über HTTP läuft, könnte man das Plugin nur auf localhost lauschen lassen und dann einen Web-Server/-Proxy davor schalten, der je nach Belieben authentifiziert und verschlüsselt.
Überlegungen gibt es, aber noch keine konkrete Umsetzung. Sehr wahrscheinlich wird es aber kein Bestandteil des Plugins. Eine externe Lösung würde das gleich für alle Webdienste des vdr erschlagen, wäre also vorzuziehen.

Lars.

Zitat von mini73

Da die Kommunikation über HTTP läuft, könnte man das Plugin nur auf localhost lauschen lassen

Wobei streng genommen hier auch wieder alle User (die nen Login haben) alle Rechte haben. svdrp hat das selbe Problem, dbus2vdr löst das elegent weil dbus hier von Haus aus schon ne Config vorsieht. Wobei man hier (dbus) AFAIK sogar den Zugriff auf bestimmte Aktionen feinregeln könnte.

Ist ja jetzt nicht so das ich erwarte das alle Welt meinen VDR hacken will Aber ich finde wenn man schon Linux mit seinem Nutzerkonzept nutzt, root nen Passwort gibt und den VDR als User laufen lässt, dann sollte man das Thema bei den Schnittstellen nicht ignorieren. Und ist halt doch irgendwie blöd wenn man weiss das jeder der sich mal mit seinen Notebook ins LAN einklingt theoretisch ohne Probleme alle Aufnahmen löschen könnte.

Zitat von mini73

und dann einen Web-Server/-Proxy davor schalten, der je nach Belieben authentifiziert und verschlüsselt.
Überlegungen gibt es, aber noch keine konkrete Umsetzung. Sehr wahrscheinlich wird es aber kein Bestandteil des Plugins. Eine externe Lösung würde das gleich für alle Webdienste des vdr erschlagen, wäre also vorzuziehen.

Wobei ich mit hier nicht vorstellen kann wie das praktisch umzusetzen wäre. Live hat ja z.B. ne Nutzerverwaltung, und ein Gastnutzer braucht dann ja ganz andere Proxyregeln wie nen Vollnutzer.

Die beste Idee die mit vorschwebt wäre ein Clientprogramm (könnte z.B. bei Win PCs ins Autostart) was alle X Minuten UserID/Passwd an den VDR sendet, der Dienst (nen kleiner Python Daemon schwebt mir vor) der das dann am VDR empfängt schaltet dann die Firewallregeln entsprechend den Nutzerprivilegien für diese IP (von der das ID Packet kam) für die nächsten Y Minuten. Wobei das erstmal nur für sowas wie den vompserver Sinn machen würde, die restfulapi nur an- oder auszuschalten ist ja auch nicht Sinn der Sache.
Wobei ich live und samba genrell von der Idee ausnehmen würde, beide besitzen ne Userverwaltung (inkl. Gastzugang) und es macht Sinn die einfach so im LAN nutzbar freizugeben.

cu

Ein paar Gedanken/Ideen:

• Mehrere VDR-Plugins haben je einen HTTP-Server eingebacken (streamdev-server, live, restfulapi). Jedes muss auf einem eigenen HTTP-Port lauschen.
• Wenn diese Plugins sich in einen CGI-Mode schalten ließen, wo der eingebaute Web-Server inaktiv ist, könnte man sie evtl. als CGI-Programme in einen unabhängigen Web-Server (Lighttpd, Nginx) auf dem gleichen Host einbinden (http://www.tntnet.org/cxxtools_cgi.cpp.html).
• Der unabhängige Web-Server selbst würde dann bestimmen, auf welchem Port welches Plugin unter welchen URLs zur Verfügung steht und kann alles auf einem Port bündeln, ohne dass der Server als Reverse-Proxy konfiguriert werden müsste. Die Web-Server-Konfiguration entscheidet, wer wo und wie Zugriff erhält.
• Hat streamdev-server eine Nutzerverwaltung, die festlegt, wer welche TV-Kanäle streamen darf?
• Die Security endet da, wo jemand mit der Fernbedienung vor dem VDR sitzt und per Fernbedienung auf dem "localhost" Aufnahmen löschen darf, ohne ein Passwort eingeben zu müssen. Insofern hat ein Angreifer mit (physikalischem) Zugriff auf den Localhost immer alle Möglichkeiten, Schaden anzurichten.

Gruß
hepi

Zitat von hepi

Die Security endet da, wo jemand mit der Fernbedienung vor dem VDR sitzt und per Fernbedienung auf dem "localhost" Aufnahmen löschen darf, ohne ein Passwort eingeben zu müssen. Insofern hat ein Angreifer mit (physikalischem) Zugriff auf den Localhost immer alle Möglichkeiten, Schaden anzurichten.

Stimmt (gegen physikalischen Zugriff kann man nix machen, aber übers Netz sollte es wenigstens halbwegs sicher sein), wobei ich da schon teilweise meine Idee umgesetzt habe alle entsprechenden Aktionen (Aufnahmen löschen, Timer löschen usw.) bei aktiver Kindersucherung zu sperren. Sind nur einige wenige Zeilen Code pro Plugin und man hat nen gastsicheren VDR.

Wobei es mir bei der ganzen Sache auch weniger um mutwillige Aktionen geht, mir gehts eher darum das einige Leute dazu tendieren einfach mal sinnlos rumzuprobieren wenn sie nicht wissen wie etwas geht und ich keine Lust habe deswegen am VDR irgendwas zu verlieren.
Ist halt mehere so eine Prinzipsache als irgendwas mit hoher Priorität.

Und mir gings hier auch nur darum das Thema wenigsten mal anzusprechen weills sonst keiner Erwähnt hat.

Zitat von hepi

[*]Hat streamdev-server eine Nutzerverwaltung, die festlegt, wer welche TV-Kanäle streamen darf?

Gute Frage, ich nutze den vomserver und der gibt jeden einfach alle Rechte. Wobei es bei dieser Frage je erstmal um den Jugendschutz geht. Der wird übers LAN auch so gut wie nie bachtet.

cu

Moin!

Authentifizierung und Authorisierung ist für mich ein ganz wichtiges Thema.

HTTPS ist nur ein Anfang, das hat damit ja eigentlich erst mal nichts zu tun, sondern sichert nur die Übertragung vor Abhören. Das sollte auf alle Fälle eingebaut werden, ist aber vom benutzten Web-Server abhängig. In diesem Fall von cxxtools bzw. es ließe sich, falls der Zugriff über einen anderen Web-Server "getunnelt" wird, eben auch dort aktivieren.

Benutzername/Passwort-Kombinationen sind zwar schön und nett, aber wenn sowas nicht richtig umgesetzt wird (Passwörter dürfen nicht im Klartext gespeichert werden, wie sicher ist der verwendete Hash-Algorithmus beim Speichern der Passwörter usw.), taugt es auch nicht. Gerade bei HTTP müsste das Passwort bei jedem Zugriff übertragen werden bzw. eine Session-ID. Und wenn man dann über einen Zwangsproxy zugreifen muss (z.B. von der Firma aus), ist eine IP-gebundene Session-ID auch wieder doof.

Mein persönlicher Favorit sind Client-Zertifikate. Da muss dann kein Passwort übertragen bzw. gespeichert werden. Aber wie das genau funktioniert, weiß ich noch nicht. Das ist halt etwas, das ich noch lernen muss. Ich stelle es mir im Prinzip wie ssh mit public-key vor, ich hoffe, ich liege da richtig.

Gehe ich richtig in der Annahme, dass lesende Operationen GET verwenden und schreibende PUT bzw. DELETE/INSERT? Dann müsste sich darüber im Web-Server eigentlich konfigurieren lassen, wer auf was zugreifen darf. Wenn wir jetzt mal ein wenig weiter spinnen und uns Live nicht als Plugin, sondern als Javascript-Anwendung im Browser vorstellen, dass auf das abgesicherte restfulapi zugreift, muss die "Live-App" noch nicht mal eine eigene Benutzerverwaltung besitzen. Einziger Nachteil ist, wenn man mal aus der Fremde (Internet-Cafe, Freunde usw.) mal eben so eine Aufnahme programmieren will. Aber wer einen vdr aus der Ferne bedienen will, muss sich dann eben ein eigenes Smartphone zulegen...

Um deine Frage zu beantworten: ja, es gibt jemanden, der darüber nachdenkt und es irgendwann gerne umsetzen möchte...
siehe auch Portnummer des WFE (Web-Front-End) bei yaVDR ändern

Lars.

Zitat von mini73

Mein persönlicher Favorit sind Client-Zertifikate. Da muss dann kein Passwort übertragen bzw. gespeichert werden. Aber wie das genau funktioniert, weiß ich noch nicht. Das ist halt etwas, das ich noch lernen muss. Ich stelle es mir im Prinzip wie ssh mit public-key vor, ich hoffe, ich liege da richtig.

Client-Zertifikate sind aus meiner Sicht nur dann sinnvoll, wenn sich die Anzahl der Clients nicht ändert. Jedem Client muss ein Zertifikat ausgestellt werden. Prinzipiell nicht schlecht, aber mit viel Aufwnad verbunden, da die Zertifikate Server- und Clientseitig verwaltet werden müssen.

Ich finde die Idee mit den Clientzertifikaten am Ende auch etwas unpraktisch. Jeder Browser bietet Support für http Authentifizierung (und mittlerweile auch für die Variante mit dem Web Formular), ferner wäre ein "eingeloggt bleiben" (per Cookies) auch OK. Und jede (also wirklich jede) Website arbeitet problemlos nach diesem Muster. Hier gehts ja nicht zum Hochsicherheitsbankanwendungen.

https wäre als Option zusätzlich ganz nett, aber AFAIK nicht das wichtigste. Abgesehen davon wird wohl niemand nen Zertifikat spendieren (was AFAIK Jährlich Geld kostet), also bleibts beim selbsterstelleten was jeder Nutzer vom VDR Webinterface runterläd und akzeptiert (Das Root Zertifikat halt halt kein Browser wenn mans selbst erstellt) nachdem der VDR Admin den Fingerprint telefonisch bestätigt hat

Wobei das alles die restfulapi überhaupt nicht betrifft, der Enduser kommt mit der restfulapi ja überhaupt nicht in Berührung, die wird in ner Webanwendung per ajax oder von Clientsoftware genutzt (und diese Fragen dann Passwort/Nutzername ab oder nutzen Zertifikate), also muss da ne Authentifizierung inkl. Berchtigungsattributen irgendwie mit ins Protokoll.

cu

Hallo,

immer wenn ich das Plugin lade bekomme ich beim beenden des VDR ein 'killed by ...' im syslog:

Den VDR beende ich mit
#> stop vdr

Aug 16 12:08:40 vdr vdr: [6014] GraphTFT plugin display thread ended (pid=5899)
Aug 16 12:08:40 vdr vdr: [5899] deleting plugin: restfulapi
Aug 16 12:08:40 vdr vdr: [5993] Netwatcher thread ended (pid=5899, tid=5993)
Aug 16 12:08:41 vdr vdr: [5899] caught signal 15
Aug 16 12:08:41 vdr vdr: [5899] exiting, exit code 0
Aug 16 12:08:41 vdr init: vdr main process (5899) killed by ABRT signal

System: yavdr 04.pre mit allen verfügbaren updates.

Scheint auch ein SEGFAULT beim beenden zu geben. Deaktiviere ich restfulapi via der order.conf ist diese Meldung weg.

Danke und Grüße,
Jörg

hmm, gearde mal geschaut

den

Aug 16 12:08:41 vdr init: vdr main process (5899) killed by ABRT signal

hab ich nicht aber in der Tat nen segfault:

Aug 16 12:19:50 CKone kernel: [ 2205.672338] vdr[5328]:
segfault at 7f506ced5910 ip 00007f506ced5910 sp 00007fffa9bee8f8
error 14 in libXdmcp.so.6.0.0[7f506da91000+5000]

welcher sich durch Deaktivieren des restfulapi beseitigen lässt.

Ist das ein generelles Problem oder eine Wechselwirkung in einer spezifischen Konfiguration?

Christian

Zitat von CKone

Aug 16 12:19:50 CKone kernel: [ 2205.672338] vdr[5328]:
segfault at 7f506ced5910 ip 00007f506ced5910 sp 00007fffa9bee8f8
error 14 in libXdmcp.so.6.0.0[7f506da91000+5000]

Hmm, aelo was machst du denn mit dem X Display Manager? Oder ist das nur ein Folgefehler?

Gerald

Irgendwie fiel mir das auch schonmal auf. Aber Abstürze beim beenden nerven mich nicht so sehr. Und der Backtrace sagt mir nix ausser das das restfulapi Pluign da irgendwie mit drinhängt.

#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb7571751 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7574b12 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb75a818d in ?? () from /lib/i686/cmov/libc.so.6
#4  0xb75b2281 in ?? () from /lib/i686/cmov/libc.so.6
#5  0xb75b3ad8 in ?? () from /lib/i686/cmov/libc.so.6
#6  0xb75b6bbd in free () from /lib/i686/cmov/libc.so.6
#7  0xb778c701 in operator delete(void*) () from /usr/lib/libstdc++.so.6
#8  0xb4f333a0 in __gnu_cxx::new_allocator<std::_List_node<BaseTask*> >::deallocate (this=0xb4f9a510,
    __in_chrg=<value optimized out>) at /usr/include/c++/4.4/ext/new_allocator.h:95
#9  std::_List_base<BaseTask*, std::allocator<BaseTask*> >::_M_put_node (this=0xb4f9a510,
    __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_list.h:320
#10 std::list<BaseTask*, std::allocator<BaseTask*> >::_M_erase (this=0xb4f9a510, __in_chrg=<value optimized out>)
    at /usr/include/c++/4.4/bits/stl_list.h:1431
#11 std::list<BaseTask*, std::allocator<BaseTask*> >::pop_front (this=0xb4f9a510, __in_chrg=<value optimized out>)
    at /usr/include/c++/4.4/bits/stl_list.h:906
#12 ~TaskScheduler (this=0xb4f9a510, __in_chrg=<value optimized out>) at tools.cpp:877
#13 0xb7576688 in __cxa_finalize () from /lib/i686/cmov/libc.so.6
#14 0xb4f27d54 in __do_global_dtors_aux () from /opt/vdr-1.6.0-2/plugins/libvdr-restfulapi.so.1.6.0
#15 0xb4f7f770 in _fini () from /opt/vdr-1.6.0-2/plugins/libvdr-restfulapi.so.1.6.0
#16 0xb78db71e in ?? () from /lib/ld-linux.so.2
#17 0xb78dc197 in ?? () from /lib/ld-linux.so.2
#18 0xb787aca4 in ?? () from /lib/i686/cmov/libdl.so.2
#19 0xb78d67f6 in ?? () from /lib/ld-linux.so.2
#20 0xb787b09c in ?? () from /lib/i686/cmov/libdl.so.2
#21 0xb787acda in dlclose () from /lib/i686/cmov/libdl.so.2
#22 0x080fceee in ~cDll (this=0x81a7bb0, __in_chrg=<value optimized out>) at plugin.c:166
#23 0x0812dc6f in cListBase::Del (this=0xbfe56000, Object=0x0, DeleteObject=148) at tools.c:1794
#24 0x080fc9d5 in cPluginManager::Shutdown (this=0xbfe55ff0, Log=true) at plugin.c:500
#25 0x08134152 in main (argc=62, argv=0xbfe56174) at vdr.c:1709

Aug 16 17:33:46 localhost vdr: [14578] receiver on device 2 thread ended (pid=1649, tid=14578)
Aug 16 17:33:46 localhost vdr: [1659] section handler thread ended (pid=1649, tid=1659)
Aug 16 17:33:46 localhost vdr: [1658] tuner on device 2 thread ended (pid=1649, tid=1658)
Aug 16 17:33:46 localhost vdr: [1649] Releasing DFB
Aug 16 17:33:47 localhost vdr: [1649] [VideoOut]: Good bye
Aug 16 17:33:47 localhost vdr: [1649] deleting plugin: streamdev-client
Aug 16 17:33:47 localhost vdr: [1649] deleting plugin: restfulapi
Aug 16 17:33:58 localhost vdr Init: Start VDR: Exiting with Signal (6)
Aug 16 17:33:58 localhost vdr Init: Giving up

cu

Ich habe nen Absturz in Verbindung mit dem Burn Pluign. Backtrace ist dort.
[Announce] Burn-Plugin 0.2.0-beta6

cu

Hi Michael

also mit der neuen Version ist der segfault hier weg.

Gruß Christian

Hallo Michael,

ne kleine Bitte: kannst du das Ding evtl n klein wenig weniger gespächig einstellen - ich brauch jetzt nicht gerade das Löschen jedes einzelnen epg image in einer linie des Syslog bestätigt haben wenn ich mal grad 20.000 Bildchen lösche?

Danke,
Christian

Hallo Michael,

epg.xml funktioniert mittlerweile auch mit Kika.
Eine Kleinigkeit zu timers.xml. Wenn ein Timer z.B. um 00:04 Uhr endet, steht als stop der Wert 4. Wäre nicht 0004 korrekt?

Danke für deine Mühen.

Grüße
Alex