Habe bei mir vor dem Update auf 4.3.4 (also noch mit 4.3.3) getestet: obwohl als "Administrator" angelegt kann man per SSH kein poweroff durchführen 😐.
Vermutlich erst, wenn der User auch in der sudoers eingetragen ist, das habe ich noch nicht getestet.
Also ohne weitere Maßnahmen kein echter Admin.
Gruss
^ Leider die Änderungen bei sudoers ( /usr/etc/sudoers ) ist nicht permanent und bei jeder neustart wird zurückgestzt.
Gibt es mittlerweile eine Lösung für die "Vollwertigen Admin-Konto Ersatz"?
Hallo und willkommen im Forum.
Mir ist bis dato leider keine Möglichkeit bekannt.
Es hilft nur der Workaround. Neuen User erstellen und in die Admin-Gruppe schubsen.
Dann den integrierten Admin deaktivieren. Wenn man ihn braucht einfach wieder aktiveren.
Schön ist zwar anders aber sonst weiß ich keine andere Lösung.
Den admin, root, Administrator wird es immer geben.
Der für mich größte Knackpunkt an der der Sicherheit der QNAPS ist, dass jeder Dienst, jede App mit admin-Rechten läuft.
Kann mich da nur anschließen.
Meine EDV-Erfahrungen beruhen auf Apple Macintosh. Früher gab es mal Mac ohne Benutzerkonten. Erst mit Umstellungen auf OS X kam die Erkenntnis, dass es aufgrund der Struktur einen Superuser root gibt. Den kann man beim Mac seit längerem deaktivieren.
Leider benötigen viele Qnap-Apps den admin ergo root damit die Sachen laufen. Wie damals viele Software unter Windows XP bis weiss nicht welche Version.
Aus meiner Sicht müsste Qnap das dringend fixen!
Bin gerade hierüber gestolpert.
Eigentlich geht das alles, nur ist es wegen des Qnap-Startmechanismus etwas frickeliger als unbedingt nötig. Man kann zwar das Admin-Konto weder löschen noch umbenennen, genauso wenig wie man root auf einem Unix-System oder Mac löschen kann, aber man kann komplett mit einem eigenen User auskommen, ohne sich je als Admin einloggen zu müssen.
Vorgehen:
In der Web-Oberfläche wird der Admin soweit ich weiß dann nicht mehr gebraucht.
Wenn man in der Shell Admin-Rechte braucht (kommt z. B. beim Backup vor, wenn man Verzeichnisse anderer Benutzer einsehen will), kann man dies mit sudo -i erreichen.
Noch sicherer wird es, wenn man den ssh-Zugang ausschließlich über ssh-Keys gestattet. Dazu muss man den ssh-Dämon mit einer eigenen Konfigurationsdatei starten (geht auch über autorun.sh, ist aber etwas hakelig). Zur Konfig von ssh siehe Anleitungen (idR. für Linux). Wenn man das macht, sollte man bedenken, dass dann auch die Eintragung AllowUsers aus der neuen Konfigurationsdatei zum Zuge kommt. Nur Benutzer, die dort eingetragen sind, dürfen sich noch einloggen. Die Zugehörigkeit zur Gruppe der Administratoren zählt nicht mehr. Seit kurzem kann man dort den Admin sogar rausschmeißen (scheint Qnap korrigiert zu haben; vorher ist der ssh-Dämon sofort abgestürzt, wenn der Admin hier fehlte). Aber wenn für den Admin keine ssh-Keys (in authorized_keys) gespeichert sind, kann er sich eh' nicht mehr einloggen.
Eine Stelle gibt es aber, wo man den admin doch noch braucht: Wenn man die Konfiguration für den ssh-Dämon zerschossen hat und dieser nicht mehr startet oder niemanden mehr einlässt, muss man sich per telnet einloggen, und das geht nur mit aktiviertem admin.
Damit dies einen NAS-Neustart überlebt, müssen die beiden Aktionen in autorun.sh ausgeführt werden
Ich glaube, ich verstehe diesen Satz nicht (wenig Linux-Kenntnisse). Kannst du ihn bitte kurz umschreiben? Danke!
Nach so vielen schicken Posts / Texten die Du bisher geschrieben hast, hätte ich nicht erwartet, dass Du es Dir jetzt so einfach machst 
Aber der Link sagt alles 
Danke!
Ich habe abgefragt, dass meine NAS eine HAL-NAS ist (s.u.) . Demgemäß habe ich den Befehl laut Anleitung gewählt. Hat nicht funktioniert (s.u.). Dann habe ich in den Einstellung geändert, im Menü "Hardware" autorun aktiviert ist und mit "übernehmen" bestätigt. Ergebnis ist die selbe Fehlermeldung wie zuvor
"special device 6 does not exist"Neustart ändert daran nichts. Wo liegt der Fehler, was kann ich tun?
Kann ich den nicht funktionierenden Schritt eventuell einfach ignorieren bzw. überspringen und gleich die Datei autoscript anpassen?
Wenn ja, ist es dann korrekt, wenn sie so lautet:
mkdir /usr/etc/sudoers
cd /usr/etc/sudoers
cat > alternativadmin.sh
admin-Name ALL=(ALL) ALL
<EOF>Nebenbei habe ich einmal versucht, die Datei anzulegen ohne dies über autorun.sh zu hinterlegen. Rückmeldung:
"can't create directory... Permission denied"Der verwendete Nutzer ist in der Administratoren-Gruppe. Im Ordner "/usr/etc" bringt die Abfrage "ls -al" folgendes Ergebnis:
drwxr-xr-x 2 admin administrators 60 2021-07-26 00:40 ./
drwxr-xr-x 9 admin administrators 200 2021-07-26 01:16 ../
-rw-r--r-- 1 admin administrators 3199 2021-07-26 00:40 sudoersDanke für jede Hilfe (ich kann mir vorstellen, es ist nicht das einfachste Unterfangen, einem Anfänger wie mir hier weiterzuhelfen...)
Bin gerade im Urlaub und daher etwas eingeschränkt.
Zum Fehler
"Device 6 does not exist"Der Fehler tritt auf, wenn der Befehl in den runden Klammern $( ) keine Ausgabe liefert, z. B. weil ein Fehler aufgetreten ist. Führe einmal nur den Befehl zwischen den runden Klammern aus, dann erhälst du die Fehlermeldung. Vermutlich fehlt nur ein sudo (s. u.).
Zu
"Permission denied"Administrator sein heißt nicht, alles zu dürfen, sondern es heißt, den Befehl sudo aufrufen zu können. Ein einem Befehl vorangestelltes sudo führt jenen Befehl als root aus. Mit sudo -i (ohne weiteren Befehl) kannst du dir eine root-Shell geben lassen. Vermutlich kommst du am besten zum Ziel, wenn du die im Link beschriebene vorgehensweise in einer root-Shell machst. (Vorsicht: Alles dürfen heißt auch alles kaputt machen zu können. Einige Befehle in Linux, die großen Schaden anrichten können, haben keine Sicherheitsabfrage.)