DSM 6.x und darunter Gruppe "Users" das DSM abgedreht -> Jetzt als Admin ausgesperrt

[dtv1899]

Die Überschrift sagt alles. Hab der Gruppe "User" alle Applikationen inkl. DSM abgedreht. Wohlwissend, dass der Admin auch da drin ist, er ja aber über die Admin Gruppe noch alle Rechte hätte haben sollen, was aber nicht so ist....

Jedenfalls habe ich jetzt via Reset Button den inaktiven Admin-Account aktiviert. Wenn ich mich mit diesem im DSM einlogge, sehe ich für zwei Sekunden den Desktop, dann wird die Seite aber komplett überlagert von der Password-Reset-Funktion des meines eigentlichen Admins. Dies bringt mir aber nichts, da er ja auch nach dem Passwortreset keinen Zugriff auf DSM haben wird.

Kann ich irgendwie über SSH der Gruppe Users wieder den Zugriff auf DSM aktivieren?

Möchte die Box ungerne komplett resetten.

 

[Fusion]

Wie sieht diese Überlagerung aus?
Kannst du den Dialog bedienen und danach im admin Konto weiter arbeiten?

Verbote wirken stärker als eine Erlaubnis...

 

[Fusion]

Habs zwar auch als Notiz in der Note Station... aber Google war schneller.

https://tech.setepontos.com/2017/05/22/block-users-from-accessing-synology-dsm-desktop/

 

[dtv1899]

Danke für den Link... leider komme ich damit nicht weiter. Muss ich das als root oder meinem User machen?
Sollte dieser Table unter Punkt 4 irgendwo erscheinen?

 

[Fusion]

Als root Benutzer.

Nein, die Tabelle muss nirgends erscheinen. Das ist nur eine tabellarische Aufschlüsselung von Punkt 3)

 

[dtv1899]

Bin schon die ganze Zeit dran, ich komme irgendwie nicht weiter. Habe schon diverse Einträge hinzugefügt, aber ich komme noch nicht rein und habe jetzt nochmal die Originaldatei von vor meiner SQLite-Bastelei restored.

Das sind die den Synodesktop betreffenden Einträge. Das bloße Hinzufügen meiner User-ID 1026 hat nichts geholfen, da wie oben erwähnt, Verbote wohl stärker sind und ich ja der ganzen Gruppe den Desktop abgedreht habe. Wie ändere ich Einträge statt welche einzufügen?

 

[Fusion]

Welche ID hat denn dein eigener Admin Benutzer? ID 1026 ist normal der erste Benutzer der angelegt wird.
Hast du dessen Privilegien mal explizit abgefragt mit AND wie auf der Seite genannt?
Oder auch mal mit der ID und ohne SYNO.Desktop?

 

[dtv1899]

Zu meinem User spuckt der Table überhaupt nichts aus da dieser weder bestimmte Verbote noch Gebote hat bzw. hatte. Lief alles über die User-Gruppe.

 

[blurrrr]

Steht doch in der passwd (wie im Link beschrieben)?

 

[Fusion]

Dann wäre der Versuch als nächstes den Eintrag komplett neu anzulegen, auch wenn er aktuell gar nicht mehr vorhanden ist.

Oder alternativ für die users Grippe 100 die Rechte wieder umzustellen (wenn ich mich nicht vertan habe)
INSERT INTO AppPrivRule VALUES(1,100,'SYNO.Desktop','0.0.0.0','0000:0000:0000:0000:0000:FFFF:0000:0000','','');

 

[dtv1899]

Das funktioniert nicht, da für Gruppe 100 ja bereits ein Eintrag (wohl die Sperre) vorhanden ist. Ich muss den entweder ändern oder löschen können. Gibt es dafür auch einen Befehl?

 

[Fusion]

Was funktioniert nicht? Bekommst du einen Fehler?
INSERT überschreibt normal Einträge die schon vorhanden sind.

 

[blurrrr]

https://www.guru99.com/sqlite-query-insert-update.html#3

EDIT: Aber gut aufpassen, haust Du daneben, kann das noch schlimmere Folgenhaben
EDIT2: "...wohl die Sperre..." Du solltest Dir "sicher" sein, dass es die Sperre ist, also vorher mit anderen Einträgen vergleichen(!)

 

[dtv1899]

Was funktioniert nicht? Bekommst du einen Fehler?

Error: UNIQUE constraint failed: AppPrivRule.Type, AppPrivRule.ID, AppPrivRule.App

Wenn ich den Eintrag aus der Anleitung übernehme, habe ich für die Gruppen ID 100 zwei Einträge drin:


Weißt du wofür der Type ganz vorne steht? Den Rest habe ich jetzt verstanden, muss es nur noch editieren können

 

[Fusion]

Dann musst du eben UPDATE verwenden.

Nein, weiß ich aus dem Kopf nicht mehr. Eventuell war es 0 Benutzer, 1 Gruppen, aber ne... ist grad Spekulatius.

 

[Benares]

Also bei mir siehts so aus:

sqlite> SELECT * FROM AppPrivRule WHERE App='SYNO.Desktop';
2|0|SYNO.Desktop|0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000||
1|106|SYNO.Desktop|||0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000
0|1032|SYNO.Desktop|||0.0.0.0|0000:0000:0000:0000:0000:FFFF:0000:0000

aber is verstehe die Zusammenhänge nicht.
Type 0 könnte UID sein, aber 1032 ist bei mir ein Drucker-User (admin ist 1024, guest 1026)
Type 1 könnte GID sein, aber 106 ist SynologyGuests (users ist 100)
Type 2 - keine Ahnung

Edit:
Der verlinkte Artikel ist auch etwas komisch, schon Punkt 1 ist merkwürdig. Da wird nach admin gesucht, aber guest gefunden, weil der der "admin" als Kommentar hat.

 

[dtv1899]

Okay ich habe es geschafft, bin wieder drin.

In Unkenntnis der genauen Befehle habe ich via UPDATE alle Einträge der User-ID 100 auf die User ID 999 geändert und dann den von @Fusion angegebenen Eintrag für die ID 100 (Users) frisch gesetzt, der sich dann auch setzen ließ.

Jetzt ist die Datenbank zwar total verbastelt, aber ich komme wieder rein.

Danke an alle!

 

[Fusion]

Wenn alles geht kannst ja die ganzen 999 löschen.

Und dann: Eigene Gruppen einrichten. Finger weg von "users".
In dieser Gruppe sollen gar keine Berechtigungen gesetzt werden, weder Verbote noch Erlaubnisse. Die Gruppe ist "Hakenfrei".
Alles andere führt nur zu Verstrickungen mit den Syno Anwendungen und Automatismen.

 

[dtv1899]

Eigene Gruppen einrichten. Finger weg von "users".

Werde ich tun. Ist meines Erachtens leider etwas irreführend gelöst.

Möchte eine Gruppe erstellen, die neuen Usern erst einmal alles verbietet, was ich dann fallbezogen wieder selektiv erlauben kann. Würdet ihr das einfach direkt auf Userebene beim Anlageassistenten machen? Aufgrund des Verbotsprinzips, würde solch eine Gruppe ja alle einzelnen Erlaubnisse wieder ausstechen.

 

[Fusion]

Ja, da hast du recht. Sinnvoller wäre gewesen Synology hätte die Zwangsgruppe "users" gar nicht in der GUI eingeblendet, oder wenigstens anders benannt. "users" ist einfach zu verlockend da dran rum zu fummeln.

Du brauchst keine Gruppe die alles verbietet, es reicht normal schon, wenn es nicht erlaubt ist. (zumal ein Verbot für die Gruppe normal, wie du gemerkt hast, stärker wiegt, als die Erlaubnis für den Benutzer)
Wenn du mindestens einen Benutzer mit korrekten Zugriffsrechten hast, bsp dein admin, dann kannst du unter Systemsteuerung > Berechtigungen mal alle Standardberechtigungen rausnehmen. Dann bekommen neue Benutzer schon mal nicht automatisch irgendwas erlaubt.