Installation als root abfragen und verhindern?

[Shadowhunter23]

@codierknecht sagte in Installation als root abfragen und verhindern?:

Die Installation ist eine Sache - das Rumpfuschen als root nach der Installation eine ganz andere ...

Wenn ich das richtig gesehen habe gibt es ein Script dass das schon kontrolliert und stoppt.
War das nicht das nodejs-update Script?

[Thomas Braun]

@shadowhunter23 sagte in Installation als root abfragen und verhindern?:

War das nicht das nodejs-update Script?

Ja, das war da mal drin. Und im iob diag war das auch mal aktiv. Da aber eher versehentlich.

Ganz aktuell gibt es aber diesen PR dazu:

https://github.com/ioBroker/ioBroker/pull/548

Und hier begleitend im Installer:

https://github.com/ioBroker/ioBroker/pull/552

Grothesk242 created this issue in ioBroker/ioBroker

closed Lock out root and sudo. #548

Grothesk242 created this issue in ioBroker/ioBroker

closed Usercheck implemented #552

[Shadowhunter23]

Da diese Thema aktiv diskutiert bin ich gespannt was dabei raus kommt.
@Thomas-Braun ich bin immer noch der Meinung das beim ausführen mit root jemand eine PayPal Spende erhalten sollte.

[Thomas Braun]

Der code funktioniert auf meiner Kiste schon:

echad@chet:~ $ sudo iob status
ioBroker must not be run as root!
Only a user that is member of iobroker group can execute ioBroker commands.
Only in very special cases you can run iobroker with --allow-root option
echad@chet:~ $ sudo iob status --allow-root
iobroker is running on this host.


Objects type: jsonl
States  type: jsonl
echad@chet:~ $ 

Aus einer root shell heraus auch:

root@chet:~# iob status
ioBroker must not be run as root!
Only a user that is member of iobroker group can execute ioBroker commands.
Only in very special cases you can run iobroker with --allow-root option
root@chet:~# 

Edit: Und bevor Dockeristen angekommen: Der Code läuft nur auf systemd-basierten Systemen, was ein Docker aber nicht ist. Allerdings in LXCs muss man als standard user agieren.

[BananaJoe]

Als jemand der ständig als root arbeitet:
Naja, das ganz wundervolle Installationsskript hatte bisher überhaupt keine Probleme damit, ioBroker trotz root richtig und funktionsfähig zu installieren.
Es wird der Benutzer und Gruppe iobroker angelegt, die Rechte für den /opt/iobroker Ordner werden richtig gesetzt.

iob fix würde - soweit ich das richtig interpretiere - eventuelle falsche Rechte korrigieren.
Die Falle lauert dann natürlich bei jedem Upgrade auf der Kommandozeile (was iob fix richten würde)

Bei einer heutigen Neuinstallation landet man aber ja normalerweise gar nicht mehr bei einem root - von RedHat vielleicht mal abgesehen. Den muss man sich ja dann erst noch extra freischalten für einen direkten Login. Da wäre aus meiner Sicht eher die Prüfung wichtig das der bei der Installation neu angelegte Benutzer nicht iobroker ist (und bitte auch keine Abwandlung davon mit Groß- und Kleinschreibung)

Das war bis ein vor ein paar Jahren natürlich anders, da war der root noch gang und gäbe, was man bei älteren Installation oft noch sieht.

Bevor es hier eine Diskussion dazu gibt: Ich weis was ich tue, ich arbeite seit über 30 Jahren mit Unix und Linux. Was nicht bedeutet das ich da alles beherrsche oder keine Fehler mache.

Mit dem root etwas kaputt zu machen bzw. der Fehler Nummer 1 dabei sind natürlich zu 99% die Zugriffsrechte. Der Klassiker ist das eine Datei als root erstellt wird und die Dienste dann mit ihren dazu gehörigen Benutzer wie iobroker, mysql, www-data oder zabbix nicht darauf zugreifen können. Oder der root macht die Tests und temporäre Dateien sind dann auch im Besitz des root und die eigentlichen Prozesse können dann nicht darauf zugreifen.
Weshalb ich ständig darauf achte in welchem Kontext etwas ausgeführt wird und eben auch genau auf die Rechte achte bzw. in den Kontext des entsprechenden Benutzers wechsle. Ich betreibe diverse Web- und Applikationsserver und da läuft jede Subdomain/vHost und jede Applikation unter ihrem eigenen, eingeschränktem Benutzer.

Das ist natürlich nichts für den Otto-Normalverbraucher. Der dann wiederum aus meiner Sicht auch viel zu oft sudo davor setzt, oft auch weil das meiste was man am Anfang macht es braucht (wie die Anpassung der Konfiguration von diversen Diensten). Das ist eines der ersten Dinge was Linux-Neulinge lernen: Du musst sudo davor tippen. Viele andere Programme fangen das aber ja auch schon ab, z.B. das pip von Python oder man müsste es wiederum expliziert umkonfigurieren/aktivieren wie bei z.B. bei Zabbix.

Fazit: Ich widerspreche ja gar nicht, "das man nicht als root arbeitet", auch wenn aus meiner Sicht die Leute eher lernen sollten den Kontext eines Benutzer zu verstehen bzw. das Dienste als bestimmte Benutzer ausgeführt werden.
Aber wenn Ihr schon dabei seit nehmt den Benutzer iobroker da auch mit rein, das wird hier auch immer bemängelt.

[haus-automatisierung]

@bananajoe sagte in Installation als root abfragen und verhindern?:

Fazit: Ich widerspreche ja gar nicht, "das man nicht als root arbeitet"

Dennoch sollten wir uns darauf einigen, niemandem den Mut zu machen es dennoch zu tun und es niemandem zu empfehlen. Wie oft lese ich "das mache ich schon immer so" und "es war noch nie ein Problem"...

[Thomas Braun]

@bananajoe sagte in Installation als root abfragen und verhindern?:

auch wenn aus meiner Sicht die Leute eher lernen sollten den Kontext eines Benutzer zu verstehen bzw. das Dienste als bestimmte Benutzer ausgeführt werden.

Das ist der Sinn des Patches. Es darf nicht (vermeintlich) 'bequemer' sein als root über das System zu rutschen denn als Standarduser mit entsprechenden Rechten. Sonst hörst du nämlich weiter das übliche:

Mach ich schon immer, nie was passiert! (Mag sein, oft haste es nur nicht gemerkt)
Bei yt macht der das auch mit root! (Mag sein, es ist aber dennoch falsch)
Es gibt nur den root account! (Mag sein, dann hast du die Rohkarosserie nie richtig ausgebaut)

[BananaJoe]

@haus-automatisierung @Thomas-Braun aus meiner Sicht stirbt es ja auch aus weil man bei neuen System gar keinen root mehr hat sondern immer gezwungen wird einen eigenen Benutzer anzulegen.

Den root-Fall über sudo würde die Änderung ja abfangen, als iobroker zu arbeiten wäre aber ja genauso falsch.

Mein Post sollte eigentlich nicht so in die "aber das geht doch" Schiene rutschen, ich wollte eher Proteste "wie kannst du nur als root arbeiten" entgegenwirken und habe wohl nun genau das Gegenteil erreicht.

Kürzen wir meine Aussage auf "ich fände gut wenn der Benutzer iobroker auch mit geprüft würde" herunter

[haus-automatisierung]

@bananajoe sagte in Installation als root abfragen und verhindern?:

aus meiner Sicht stirbt es ja auch aus weil man bei neuen System gar keinen root mehr hat sondern immer gezwungen wird einen eigenen Benutzer anzulegen.

Zumindest die Standard Container-Templates von Proxmox kennen erstmal nur root. sudo muss man dazu installieren und einen Benutzer muss man auch anlegen.

In der Standard-Installation von Debian muss man das root-Passwort leer lassen bei der Einrichtung. Dann wird der erste angelegte Benutzer zum "sudoer". Vergibt man ein Passwort, hat man auch dort nach wie vor root.

[Thomas Braun]

@bananajoe sagte in Installation als root abfragen und verhindern?:

Kürzen wir meine Aussage auf "ich fände gut wenn der Benutzer iobroker auch mit geprüft würde" herunter

Hatte ich auch auf dem Radar, aber dann doch nicht umgesetzt. Den User müsste man dann eigentlich auch wieder auf 'nologin' setzen, so wie er auch vom Installer angelegt würde. Du würdest ja die User 'enteignen'.
Der Eingriff war mir dann aber doch zu groß, erstmal den root-Sumpf trocken legen.

aus meiner Sicht stirbt es ja auch aus weil man bei neuen System gar keinen root mehr hat sondern immer gezwungen wird einen eigenen Benutzer anzulegen.

Leider nicht wirklich. LXCs werden z. B. oft nicht komplett aufgesetzt, da bleibt es beim 'Rohbau' mit dem root und es werden keine User mehr angelegt. Und dann haste noch die User, die dir triumphierend sagen, das sie als l337-haX0r der sie sind ausgetüftelt haben, wie man eine root shell aufreißt.