Beiträge von BarneyBurp

Hallo
Es tut mir leid ein so altes Thema wieder hervorzuholen, aber irgendwie erscheint es mir nicht korrekt, dies als "Erledigt" markiert zu sehen.

Bei der hier erwähnten Einstellung bzw. eine Mailadresse ohne Postfach zu erstellen, laufe ich auf selbigen Fehler bzw. das mir ein "authentication failure" zurückkommt.

Gab es hierzu mal eine schlüssige Erklärung bzw. warum das denn so ist?

Das Problem ist einfach, das diese Konfigurationsmöglichkeit weiterhin besteht und weiterhin zu diesem problematischen Verhalten führen kann.

Ich denke du gehst damit quasi genau den richtigen Weg
Ich bin überhaupt kein Kenner jeglicher JS Backends aber bei ziemlich vielen anderweitigen z B ApplicationServer oder Webservern gibt es meist entsprechende Shellskripte wie start.sh, stop.sh, (status.sh).

Diese machen im Prinzip neben einigen anderen ENV Dingen genau das was du machst. Die PID in eine Datei speichern sodass in einer anderen Sitzung zu einem anderen Zeitpunkt per stop.sh die laufende PID gefunden und gekillt werden kann. Weiter wird meist dafür gesorgt, das bei einem schon gestartetem Prozess, kein anderer, per start.sh, gestartet wird. Die status.sh kann dann noch Dinge über das Laufzeitverhalten ausgeben.
Es ist im Prinzip genau so (vereinfacht) strukturiert wie man es bei einem Service (systemd, init.d etc.) machen würde. Das ist tatsächlich, zumindest meines Wissens nach, die beste Alternative wenn man keinen Zugriff auf anderweitige Hintergrundprozessverwalter hat.

Eine Integration bzw. einen Zugriff per Plesk oder CP wäre natürlich sehr angenehm

In dem Falle ist es wohl richtig. Sudo hat in diesem Sinne keinen Sicherheitsvorteil bzw. "nur" einen Abstraktions/Tracevorteil.

Allerdings finde ich es, selbst als Einzelnutzer eines Systems, deutlich angenehmer mit sudo zu arbeiten. Einfach um kritische Ausführungen von z.B. unbekannten Skripten zu verhindern.
Habe ich eine Rootshell, ist schnell mal was ausgeführt was ich eventuell gar nicht beabsichtigt habe, dann halt direkt als Root.
Natürlich muss jeder selber aufpassen und trotzdem kann mal was daneben gehen (auch mit sudo)

Zitat von DC2022

Ich empfinde das eher als Nachteil, da der Nutzer dann ja ohne zusätzliche "Barriere" sudo ausführen kann?

Dann hast du einen Non-Root Benutzer, der aber in der Sudo Gruppe drin ist und ohne zusätzliches Passwort per Sudo alles ausführen kann? Ist das nicht unsicherer?

Also ja und nein. Dann ist es nicht möglich zumindest als Root direkt eine Shell zu bekommen bzw. zumindest nicht ohne z.B. sudo.
Genau dann hat man quasi einen NonRootnutzer der mit seinem Passwort über sudo Rootbefehle ausführen kann.
Auf deine Benutzer- bzw. allgemein Passwörter muss du allerdings so oder so aufpassen

Wenn du jetzt an jeden Nutzer deines Systems, uneingeschränkt sudo vergibst, hat jemand mit diesem einen Passwort leichtes spiel. Andersherum wäre es aber auch problematisch, wenn dein einer Nutzer der nur per su zum Root werden kann ständig dein RootPW erfragt.

Am sichersten ist es natürlich gar kein Root zu benötigen

Zitat von Exception

Das ist nicht ganz richtig. Sudo hat rein gar nichts mit dem Befehl su zu tun und ist damit nicht vergleichbar. Mit su wechselst du einfach nur den Benutzer. Das kann der Root sein aber auch irgendein anderer Benutzer. Wichtig ist allerdings, dass du dafür entsprechend das Kennwort des Benutzers brauchst. Ist also wie als wenn du in Windows den Benutzer wechselst.

Sudo ist ein Tool, mit dem der Benutzer einen Befehl mit dem Namen und den Berechtigungen von Root ausführt. Vorausgesetzt der Benutzer ist dafür Berechtigt. Der Benutzer muss also nicht das Kennwort von Root wissen!

Das ist halt doch ein großer Unterschied.

Das stimmt Mit su wechselt man tatsächlich nur einen spezifischen Nutzer. Hier hatte ich jedoch explizit "su" angenommen ohne irgendwelche NutzerID/Nutzer als Parameter. Somit wird per Default der Rootnutzer genommen -> man pages "... When called with no user specified, su defaults to running an interactive shell as root. ..."

Meine "vielleicht zweifelhafte" Meinung dazu

Ob nun sudo oder su, mit beidem hast du Rootrechte bzw. um die man hier und da auch nicht drum herum kommen wird;)

Durchgesetzt hat sich meiner Meinung schon die einzelne Ausführung von Commands mit sudo.

Sudo bietet im Prinzip "nur" folgende Vorteile der Nachvollziehbarkeit und einen eventuell gewissenhafteren Einsatz:

• Per sudo ist es nicht notwendig irgendwie/irgendwo das singulär vorhandene Root PW einzutippern
• Du kannst quasi jeden Nutzer per sudo'er Datei/Gruppe einzeln verwalten und diesem Rootrechte per sudo geben
• Du kannst für jeden Nutzer festlegen, welche z.B. Commands/Befehele erlaubt sind und welche nicht bzw. welche mit erhöhten Rootrechten ausgeführt werden dürfen -> Black/Whitelist
• Es ist möglich, die sudo Aktivitäten zu loggen bzw. welche Commands/Befehele von einem spezifischen Nutzer ausgeführt wurden.
• Durch das fehlen einer Rootshell, kann nicht versehentlich irgendein Befehl mit Rootrechten ausgeführt werden bzw. es muss erst sudo geschrieben werden. (Jedoch mit sudo -i, sudo su bekommt man auch eine Login/Rootshell. Das kann ab und an auch praktisch sein ;))

Ich würde z.B. den Rootnutzer komplett deaktivieren.

Genau und zum Thema SSH würde ich ebenfalls zu einem Public/Private Key greifen und am besten einen PW-Login im SSH Daemon/Server verbieten, wenn es möglich ist bzw. auch einen Rootlogin.

Zitat von backdoor

Das ist übrigens Quark. Mit dem Flag kann man bei run nur explizit festlegen, welches Image gezogen werden soll. Es findet keine Emulation statt. D.h. auch, existiert kein Image für die aktuelle Plattform oder zieht man ein Image für eine fremde Plattform, ist das Image nicht lauffähig auf der aktuellen Plattform.

Der --platform Parameter bei run sollte nur explizit angeben welches images man auf einer multiplatform zum laufen bringen möchte -> Oh ich sehe du hattest dies bereits erwähnt :).
Ansonsten muss man solch ein Image selbst bauen bzw. den --platform Paremeter bei buildx build mit angeben.
Ansonsten sollte man aber auch auf einem ARM per z.B. qemu/limavm (https://lima-vm.io/docs/) komplett docker x86/amd64 images zum laufen bekommen. Ist dann eben nur dementsprechend langsam
Aus der Praxis kann ich sagen das so was sehr gut klappt auf einem macOS mit den normal gängigen Clients wie Rancher/DockerDesktop. Nur eben doch deutlich langsamer. Obwohl mit dem Apple Virtualization Framework dann doch nochmal schneller. Das wird aber wahrscheinlich nicht auf Serverseite verfügbar sein

Ich warte noch auf einen 1000'er ARM falls so was mal kommen sollte

ARM sollte kein Problem für Docker sein.Natürlich ist es schöner fertig gebaute Images zu nehmen aber notfalls baut man einfach selber.
Genau wie schon erwähnt funktioniert das auch plattformunabhängig via qemu buildx und binfmt
https://docs.docker.com/build/building/multi-platform/