Forum

Results 1 to 12 of 12
  1. #1
    Join Date
    July 2009
    Posts
    38

    Angelegte Serverquerylogins werden als GuestServerQuery behandelt

    Huhu,

    wie der Titel es schon sagt, werden über den Client angelegte SQLs als Guest-SQLs behandelt, was a) totaler nonsens ist und b) somit ein Bug ist, weil diese ja angelegte User sind, welche in einer Servergruppe des zugehörigen TS-Servers sind und darüber die Persmissions erhalten.

    Somit kann es nicht sein, dass ein SQ, der mit SQLs eines SA-Members gefüttert wird, diese Rechte angeblich nicht haben soll und einen Fallback auf den Guest-SQL macht.

    Der Guest-SQL ist ausschließlich für SQs da, die KEINEN Login benutzen, immerhin wird serveradmin ja auch nicht als Guest-SQL betrachtet und vor Version 3.3.x gab es auch nie Probleme damit und ich habe schon seit 3.x.x dem Guest-SQ ALLE RECHTE aus Sicherheitsgründen entzogen und werde den Teufel tun, Rechte wieder zu vergeben.

    Fixt den Spaß bitte, weil angelegte SQLs über Benutzer mit dementsprechenden Servergruppen und Rechten IMMER ein User-SQL sind und KEIN Guest-SQL!!!

    Und nein, mit einer IP-Whitelist hat es nichts zu tun!
    Und nein, Serverversion und Clientversion sind nicht veraltet!
    Und nein, YaTQA ist nicht veraltet!
    Und nein, es wird für den Guest-SQL KEINE RECHTE GEBEN!
    Und nein, Änderung der Gruppensortierung über die GroupID ändert auch nichts daran!
    Und ja, es wurde geprüft und festgestellt, dass trotz Logindaten der SQL als Guest-SQL behandelt wird, was falsch ist!

    Fazit: Es ist ein fetter und kritischer Bug in TS 3 Server 3.3.0, der schnellstmöglich gefixt gehört, danke.

  2. #2
    Join Date
    June 2008
    Posts
    17,941
    Wie stellst du denn bitte fest, dass du als ServerQuery Guest behandelt wirst

    Hab das mal gerade mit Server 3.3.1 als SA mit eigenem Login versucht nachzustellen, aber ohne Erfolg.
    Wenn ich eingeloggt war ging alles wie gewünscht.

    Code:
    logout
    error id=0 msg=ok
    use 1
    error id=0 msg=ok
    clientmove clid=3 cid=2
    error id=2568 msg=insufficient\sclient\spermissions failed_permid=204
    login dante p6u4Shyg
    error id=0 msg=ok
    clientmove clid=3 cid=2
    error id=0 msg=ok
    
    
    logout
    error id=0 msg=ok
    use 1
    error id=0 msg=ok
    clientkick clid=3 reasonid=4 reasonmsg=just\sfor\sfun
    error id=2568 msg=insufficient\sclient\spermissions failed_permid=201
    login dante p6u4Shyg
    clientkick clid=3 reasonid=4 reasonmsg=just\sfor\sfun
    error id=0 msg=ok
    
    
    logout
    error id=0 msg=ok
    use 1
    error id=0 msg=ok
    clientkick clid=3 reasonid=5 reasonmsg=just\sfor\sfun
    error id=2568 msg=insufficient\sclient\spermissions failed_permid=199
    login dante p6u4Shyg
    error id=0 msg=ok
    clientkick clid=3 reasonid=5 reasonmsg=just\sfor\sfun
    error id=0 msg=ok
    Gibst du mal bitte ein Beispiel und zeigst uns deine Rechteübersicht vom User, der sich da einloggt?

    Ps dein Server ist veraltet und was in YaTQA passiert ist nicht relevant für uns, so lange es im Query Interface funktioniert.
    Ist aber auch unwarscheinlich, dass es überhaupt etwas mit YaTQA zu tun hat. Dafür wird es gut gepflegt.
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  3. #3
    Join Date
    July 2009
    Posts
    38
    Auf die 3.3.1 werde ich heute Nachmittag aktualisieren. Mich wundert es gerade, warum darüber (noch) keine Infomail bei mir eingegangen ist ... verspätet sich wohl mal wieder :S

    Screens von den Rechten kann ich gerne tätigen, die dann auch heute Nachmittag hier gepostet werden. Ich nutze für die Images den Hoster Imgure, was kein Problem darstellen sollte

    Was ich mich gerade frage, wo sich das Query Interface im Client versteckt hat. Ich suche das auch schon die ganze Zeit *grübel* ...

  4. #4
    Join Date
    June 2008
    Posts
    17,941
    Bitte kein Screenshot.
    Bitte ein Beispiel was bei Dir nicht geht und dann eine Rechteübersicht (exportierte txt und nicht nur ein Bild).

    Im Client gibt es kein Query. Du brauchst Telnet.
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  5. #5
    Join Date
    July 2009
    Posts
    38

    Angry

    1. Eine Exportfunktion der Rechte im TXT-Format, ist nicht möglich, da dies wohl ebenfalls mit der Querykonsole entfernt wurde oder niemals eingebaut war.
    2. Telnet wird nicht genutzt, zu unsicher. Entweder aus dem Programm heraus oder auf die Aussagekräftigen Screenshots gucken, danke. Hierbei bitte beachten, dass ich als ATHP Kunde bin und somit berechtigt bin, die Nachweise zu liefern, wie es mir möglich ist. Der Weg, über die Funktion Telnet und TXT-Export ist nicht möglich! - Wenn das hier im Forum als "mangelhaft" bezeichnet wird, muss ich ein Ticket über meinen ATHP-Login mit Beschwerde und Verweis hierauf tätigen, da man anscheinend nicht dem Kunden helfen möchte

    B2T ... ich habe einen meiner Zweitaccs auf das betroffene TS eingeloggt und diesem SA-Rechte gegeben, die u. a. folgende Queryrechte haben:

    https://i.imgur.com/y2XK8dl.png und https://i.imgur.com/KbR30fi.png

    Der Guest-SQ hat hingegen diese Rechte nicht:

    https://i.imgur.com/s6mvojB.png und https://i.imgur.com/3xTxrZh.png

    Nutze ich nun die Logindaten mit dem User "testacc" und dem Passwort, was mir der Querylogin angezeigt hat, erhalte ich allein in YaTQ folgende Meldung: https://i.imgur.com/KKQZ6fl.png und das, obwohl ich als SA das dafür notwendige Recht habe (ebenso das Recht, mir einen SQL zu machen und mich damit auch einzuloggen).

    Direkt danach werde ich zur Serverliste weitergeleitet, die nicht abrufbar ist, weil das Recht nicht vergeben wurde (weder bei SA, noch bei Guest-SQ), erhalte aber diesen Fehler: https://i.imgur.com/RwfuRdw.png und zu permID 22 habe ich diese Bezeichnung gefunden:

    permid=22 permname=b_virtualserver_select permdesc=Select a virtual server

    Da YaTQA lediglich eine Portspalte hat (für einen direkten Serverselect), habe ich diesen beim Login auch angegeben, was aber zu dem obigen Fehler mit permID 22 verweist. Danach habe ich die Möglichkeit, den Server mithilfe des Ports aber auch über seine ID auszuwählen (in YaTQA, nach dem Fehler) und selbst da lässt der Query wegen fehlender permID 22 keinen "use" zu.

    Das Resultat mit Version 3.3.1: Selbiges, wie oben Beschrieben, mit Version 3.3.0. Auch hier wird wieder versucht, über den Guest-SQ alles zu tätigen, was nach wie vor ein Ding der Unmöglichkeit ist.

  6. #6
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,335
    Ich verstehe nicht, was im OP Verständnisfehler und was überhaupt Probleme sind.

    Verständnisfehler gibt es definitiv, daher hier ein bisschen Basiswissen:

    Basiswissen zu lokalen Servergruppen:
    • Einige Rechte aus dem Rechtecluster "Global" haben keine Wirkung.
    • Lokale Servergruppen wirken erst, wenn man auf einem virtuellen Server ist.
    • Das gilt auch für Rechte wie b_serverinstance_permission_list, die global sind aber lokalen Gruppen gegeben werden können.


    Basiswissen zur Query-Gast-Gruppe:
    • Die jeweilige Gast-Gruppe des Servers ist eine Gruppe, die nur Voice-Clients haben können. Seit 3.0.11 haben Query-Clients immer die Query-Gast-Gruppe.
    • Wenn man Query-Gast-Gruppe b_serverquery_login wegnimmt, kann man seine Instanz in die Tonne kloppen. Wenn du sagst, du hast dem Query-Gast ALLE RECHTE weggenommen, dann ist deine Instanz nicht mehr funktionsfähig.


    Beschreibt doch mal dein Problem in einem Satz, Nein, der Titel ist nicht ausreichend, da fehlt das "wo".

  7. #7
    Join Date
    July 2009
    Posts
    38
    Quote Originally Posted by numma_cway View Post
    (...)

    Beschreibt doch mal dein Problem in einem Satz, Nein, der Titel ist nicht ausreichend, da fehlt das "wo".
    Auch wenn ich den meisten Teil aus dem Quote genommen habe, danke ich dir, für deine Antwort und möchte nachfragen, wie das "wo"
    gemeint ist.

    Was ich soweit sagen kann ist, dass der Guest-SQ zwar über das Loginrecht verfügt, aber alle anderen Rechte entzogen wurden, aus Sicherheitsgründen. Somit funktioniert z. B. kein TS-Viewer mehr, ohne einen SQL, mit dementsprechenden Rechten.

    Nun ist es so, dass man der Servergruppe Rechte zuteilen kann, u. a. Channelverwaltung, Gruppenverwaltung usw., aber auch Query-Rechte, wie b_serverquery_login oder die Abfrage nach der Version oder das "use"-Recht (permID 22).

    Wenn man nun einen sogenannten SQL sich zulegt und sich damit einloggen möchte, z. B. in einem Webinterface oder einen Bot damit laufen lassen (z. B. Java) will, dann muss man selbstredend sich authentifizieren, was entweder als "serveradmin" mit Vollzugriff möglich ist, oder als Guest-SQ, was sinnlos ist, da dieser niemals Rechte im Bereich Gruppenverwaltung/Channelverwaltung/Serververwaltung haben sollte, oder man nutzt den sich angelegten SQL, welcher exakt die Rechte beinhaltet, die nur für diesen Server gelten.

    Beim Login muss daher eigentlich wie folgt, unterschieden werden:

    A) User = serveradmin & PW korrekt => Login als Server-Query-Admin mit Vollzugriff
    B) User = leer & PW = leer (beide nicht eingetragen) => Login als Guest-Server-Query, mit dementsprechend stark eingeschränkten Rechten, je nach Vergabe.
    C) User = Client SQL & PW korrekt => Login als der angegebene User mit direktem Check, welche Rechte der User der betroffenen Gruppe hat. Wenn dort u. a. "use" vergeben wurde und beim Login ein Port bzw. die SID angegeben wurde, dann sind die cmd's auszuführen und müssen den Guest-SQ übergehen, da der User gar kein Gast ist, sondern ein in der Datenbank registrierter Benutzer, mit einer Gruppenzugehörigkeit und damit verbundenen Rechten. Hat die dem User zugeordnete Gruppe jedoch ebenfalls die benötigten Rechte nicht, sende dem User die dazugehörige Fehlermeldung und fertig.

    So hat es abzulaufen, andernfalls ist der SQL - sorry dafür - für'n Arsch und nicht mehr länger gebräuchlich.

    Edit: Was ich nebenbei in meiner Server-0-Log gesehen habe, verwundert mich ein wenig:

    2018-08-26 17:41:06.300192|ERROR |DatabaseQuery | |db_exec() update servers set server_month_upload= server_month_upload + 0, serv error: Out of range value for column 'server_total_download' at row 1
    2018-08-26 17:41:07.001193|ERROR |DatabaseQuery | |db_exec() update servers set server_month_upload= server_month_upload + 0, serv error: Out of range value for column 'server_total_download' at row 1
    2018-08-26 17:41:10.205509|ERROR |DatabaseQuery | |db_exec() update servers set server_month_upload= server_month_upload + 0, serv error: Out of range value for column 'server_total_download' at row 1
    2018-08-26 17:41:11.707611|ERROR |DatabaseQuery | |db_exec() update servers set server_month_upload= server_month_upload + 0, serv error: Out of range value for column 'server_total_download' at row 1
    Ich frage mich, wo das herkommt. Möglicherweise vom letzten Serverimport oder ist auf einen meiner vermieteten Server mit falschen Einstellungen am laufen? Weil den habe ich erst seit kurzem. DB läuft über MariaDB.
    Last edited by Chaos234; August 29th, 2018 at 08:45 AM.

  8. #8
    Join Date
    June 2008
    Posts
    17,941
    Wir haben uns deinem Report noch einmal befasst und sind zu dem Beschluss gekommen, dass es hierbei weder um einen Bug oder eine Sicherheitslücke handelt. Das ist auch keine Änderung die erst in die letzten Server eingeflossen ist. Wenn use auch schon in Server 3.0.x entfernt wird, kann man keinen Server auswählen.

    Aktuell ist es so designed und vielleicht nicht optimal für deinen Fall, aber dennoch kein Bug.

    Wie numma_cway schon gut beschrieben hat, sind deine Rechte erst aktiv, wenn du den Server ausgewählt hast.
    Da du nun aber dem Guest Query das Recht genommen hast den Server auszuwählen, hast du Dir alles verbaut.

    Die beste Lösung aus unserer Sicht ist:
    Entferne alle Rechte bis auf b_serverquery_login und b_virtualserver_select. Jetzt kann dieser Guest Query nichts weiter machen außer sich einloggen oder den Server auswählen.

    -------------------Rechteübersicht--------------------------

    Eine Rechteübersicht macht man im Client und nicht per Telnet oder sonstige Tools (Rechtsklick auf den Client im Server Tree -> Rechte -> Rechteübersicht).

    -------------------Telnet unsicher--------------------------

    Mit Server 3.3.1 kannst du auch SSH aktivieren (bitte Changelog dazu lesen), falls du mehr Sicherheit benötigst.


    -------------------SQL Fehler-------------------------------
    Kannst Du uns bitte mal eine Kopie deiner server_clear_traffic_stats.sql zukommen lassen die du im sql Ordner findest.
    Zusätzlich wäre es nett, wenn Du uns die Ausgabe vom SQL Befehl describe servers; geben könntest.
    Last edited by dante696; August 30th, 2018 at 08:02 AM. Reason: removed yatqa part
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  9. #9
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,335
    YaTQA unterstützt seit YaTQA 3.3 (16 Jun 2015) SSH, zunächst nur getunnelt über den SSH-Zugang zum Server. Seit 3.9.2-beta (08 May 2018) ist das Feature Bestandteil der Basisversion. Das SSH in TeamSpeak wird seit dem 28 Jun 2018, an dem die entsprechende Beta veröffentlicht wurde, ebenfalls unterstützt.

    Zum Exportieren eignet sich die Rechteübersicht in TeamSpeak, die in YaTQA kann nicht sinnvoll exportiert werden. Sollte ich mal ändern.

  10. #10
    Join Date
    July 2009
    Posts
    38
    Quote Originally Posted by dante696 View Post
    Wir haben uns deinem Report noch einmal befasst und sind zu dem Beschluss gekommen, dass es hierbei weder um einen Bug oder eine Sicherheitslücke handelt. Das ist auch keine Änderung die erst in die letzten Server eingeflossen ist. Wenn use auch schon in Server 3.0.x entfernt wird, kann man keinen Server auswählen.

    Aktuell ist es so designed und vielleicht nicht optimal für deinen Fall, aber dennoch kein Bug.

    Wie numma_cway schon gut beschrieben hat, sind deine Rechte erst aktiv, wenn du den Server ausgewählt hast.
    Da du nun aber dem Guest Query das Recht genommen hast den Server auszuwählen, hast du Dir alles verbaut.

    Die beste Lösung aus unserer Sicht ist:
    Entferne alle Rechte bis auf b_serverquery_login und b_virtualserver_select. Jetzt kann dieser Guest Query nichts weiter machen außer sich einloggen oder den Server auswählen.
    Verbaut eher weniger, weil es ja zum momentanem Stand nur ein fehlendes Recht ist, was ich wieder vergeben muss, es wäre nicht verkehrt, dies ggf. zu ändern. Zwar ist es keine Sicherheitslücke, aber es gibt genug Leute da draußen, die alles
    versuchen und es sogar mit Minimalrechten hinbekommen

    Quote Originally Posted by dante696 View Post
    -------------------Rechteübersicht--------------------------

    Eine Rechteübersicht macht man im Client und nicht per Telnet oder sonstige Tools (Rechtsklick auf den Client im Server Tree -> Rechte -> Rechteübersicht).
    Hab ich mal nachträglich noch angehangen. Da der damit verbundene Server importiert ist, hat der dortige Owner einige Werte etwas sehr hoch gesetzt ... einfach bitte überlesen, danke ^^'
    Quote Originally Posted by dante696 View Post
    -------------------Telnet unsicher--------------------------

    Mit Server 3.3.1 kannst du auch SSH aktivieren (bitte Changelog dazu lesen), falls du mehr Sicherheit benötigst.
    Muss ich mir bei Gelegenheit mal anschauen, weil mein SSH kein plain/pw Login mehr zulässt, sondern nur noch über Zertifikat.
    Wenn das nicht gehen sollte, bitte auf die TODO packen, um es später zu unterstützen .

    Quote Originally Posted by dante696 View Post
    -------------------SQL Fehler-------------------------------
    Kannst Du uns bitte mal eine Kopie deiner server_clear_traffic_stats.sql zukommen lassen die du im sql Ordner findest.
    Zusätzlich wäre es nett, wenn Du uns die Ausgabe vom SQL Befehl describe servers; geben könntest.
    Hier der code von server_clear_traffic_stats.sql:
    Code:
    update servers set server_month_upload= 0, server_month_download= 0 where server_machine_id=:machine_id:
    Befehl describe servers:
    Click image for larger version. 

Name:	Wr0MRQb.png 
Views:	35 
Size:	22.9 KB 
ID:	17056
    Attached Files Attached Files

  11. #11
    Join Date
    June 2008
    Posts
    17,941
    Auf dem Bild sieht man den Fehler.
    In deiner DB wird int(10) genutzt und lässt nur maximal 4294967295 zu. Die hast du überschritten.
    Richtig wäre hier aber bigint(20). Vermutlich gibt es deine DB schon vor 2012, denn da war das noch so.

    Das sollte den Fehler beheben. Bitte mache vorher unbedingt ein Backup der Datenbank!
    Code:
    ALTER TABLE servers MODIFY COLUMN server_month_upload BIGINT;
    ALTER TABLE servers MODIFY COLUMN server_month_download BIGINT;
    ALTER TABLE servers MODIFY COLUMN server_total_upload BIGINT;
    ALTER TABLE servers MODIFY COLUMN server_total_download BIGINT;
    ALTER TABLE clients MODIFY COLUMN client_month_upload BIGINT;
    ALTER TABLE clients MODIFY COLUMN client_month_download BIGINT;
    ALTER TABLE clients MODIFY COLUMN client_total_upload BIGINT;
    ALTER TABLE clients MODIFY COLUMN client_total_download BIGINT;
    When sending me private messages: Please make sure to include reference link to your forum thread or post.

    TeamSpeak FAQ || What should i report, when i open a client thread?

  12. #12
    Join Date
    July 2009
    Posts
    38
    Ja, der Mainframe ist genau so alt, wie die ATHP-Lizenz, was zu der Zeit war, als noch MySQL als Plugin, nebst SQLite, angeboten wurde.
    Da hat es wohl bei der Umstellung von MySQL auf MariaDB einen Fehler gegeben, der aus dem INT keinen BIGINT gemacht hat.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 1
    Last Post: September 1st, 2017, 02:21 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •