[gelöst] Rechte /var/www/html für VS-Code und FTP

[miriki]

Moinsens!

Ich schaue mir gerade VS-Code an. Bislang kenne ich eher den "großen Bruder", also ohne das "Code", unter Windows. Aber für HTML einerseits, aber auch Python oder C, könnte es eine für mich angenehme Umgebung auf dem Debian 11 sein. (Mit KDevelop werde ich irgendwie nicht warm.)

Nun ist es grundsätzlich kein Problem, als user "miriki" in ~/projects/... irgendwelche Projekte zu bearbeiten. Aber es geht ja auch um /var/www/html.

Dort sind die Einträge eigentlich alle auf 644 root:root. Vereinzelt waren miriki:miriki dazwischen, durch das Reinkopieren per root aus dem miriki-Home. Und irgendwas war auch als www-data angelegt, weiss aber nicht mehr genau, was. Durch "chown -R" ist das alles wieder gerade gezogen.

Klar _kann_ ich mit "sudo code" dort auch als root editieren. Aber möchte ich das? Code meldet beim Start dann ja auch Entsprechendes:

Code: Alles auswählen

miriki@lxdeb1130:/var/www/html$ sudo code
[sudo] Passwort für miriki: 
You are trying to start Visual Studio Code as a super user which isn't recommended.
If this was intended, please add the argument `--no-sandbox`
and specify an alternate user data directory using the `--user-data-dir` argument.

Und der Apache möchte per PHP ja auch vielleicht mal Daten schreiben können. Macht es Sinn, ein Wechsel der Dirs/Files auf www-data zu machen und miriki mit in diese Gruppe zu nehmen, oder ist das auch Murks? Was wäre dann eine sinnvolle Alternative?

Erweiterung: Ich würde den html-Space später vielleicht auch gerne über ftpd frei geben, um dann mit NotePad++ von Windows aus direkt in dem Verzeichnis bearbeiten zu können. Das würde bei kleinen Änderungen reichen, ohne gleich eine rdp-Session zu öffnen.

Gruß, Michael

[uname]

Also Visual Studio kenne ich nicht. Dazu kann ich dir nicht viel sagen.

Code: Alles auswählen

sudo code

Damit wird ein ausführbares Programm "code" (als root) ausgeführt. Teste z. B.

Code: Alles auswählen

sudo whoami

Dafür musst du aber sudo für in dem Fall deinen Benutzer konfigurieren. Hast du scheinbar nicht getan.
Vielleicht hast du auch zu viel bei Ubuntu gelesen. Da wäre es direkt möglich gewesen. Aber sinnvoll wäre es wohl auch dort nicht gewesen.

Auf Webservern nutzt man öfter z. B.

Code: Alles auswählen

sudo -u www-data befehl ...

um mit Benutzer root als www-data z. B. php auszuführen. Schau dir z. B. Befehl occ Nextcloud als www-data (Webserver/Nextcloud-Benutzer) an.

Insgesamt würde ich die Software www-data belassen und somit einmalig oder immer wieder die Rechte anzupassen.
Das mit der Zuordnung der Gruppe für deinen Benutzer geht. Hat mir persönlich aber noch nie gefallen.

Ich würde den html-Space später vielleicht auch gerne über ftpd frei geben

Egal was aber bitte kein FTP. Das ist ja sowas von 1990er.

Software schreibe ich direkt im Browser z. B. mit Tiny File Manager (Demo). Dann gehört es sofort www-data.
Wenn schon Remote dann sftp (auf Basis von SSH), welches mit FTP nichts zu tun hat.

[miriki]

Code: Alles auswählen

sudo code

Damit wird ein ausführbares Programm "code" (als root) ausgeführt. [...] Dafür musst du aber sudo für in dem Fall deinen Benutzer konfigurieren. Hast du scheinbar nicht getan.

Ähm... ??? Also sudo läuft hier eigentlich völlig klaglos bislang.

Bislang nutze ich ja z.B. "sudo mc", um dann mit dem MC-internen Editor in /var/www/html editieren zu können. Also das ist nicht das Problem.

Unschön (und ja auch vom Programm angemerkt) ist, wenn ich versuche, "code" (also: Visual Studio Code) per sudo zu starten. Ohne die sudo-Rechte könnte ich aber nicht in /var/www/html edtieren.

Deswegen ja meine Frage, ob ich die Files dort von root auf www-data umsetzen sollte, den User miriki (also mich als reale Person, der übliche Login) in die Gruppe www-data aufnehmen sollte und ob das dann ein sinnvoller Weg ist, dort zu edtieren. Ich sehe dann allerdings das Nervige bei neu anzulegenden Files. Wenn die dann als miriki:miriki angelegt werden (können?), muss ich die erstmal mit chown umsetzen. Aber da könnte vielleicht ein sticky im html-Stammverzeichnis helfen.

Auf Webservern nutzt man öfter z. B.

Code: Alles auswählen

sudo -u www-data befehl ...

Naja, Apache2 läuft hier bereits als www-data:www-data, soweit /etc/apache2/envvars benutzt wird.

Das mit der Zuordnung der Gruppe für deinen Benutzer geht. Hat mir persönlich aber noch nie gefallen.

Hm, warum nicht?

Ich würde den html-Space später vielleicht auch gerne über ftpd frei geben

Egal was aber bitte kein FTP. Das ist ja sowas von 1990er.

Jup, war auch mehr so erster Gedanke. Hab mittlerweile vsftpd laufen. NotePad++ kriegt Dateien geöffnet, kann Änderungen aber nicht speichern. NP sagt leider nur lapidar "failed" und auf Linux-Seite sehe ich keine Log-Einträge. Aber dem komme ich auch noch auf die Spur.

Gruß, Michael

[DeletedUserReAsG]

Es ist eine sinnvolle Sache, die geringstmöglichen Rechte zu nutzen, nicht die maximal Möglichen, wie es sudo code nunmal macht. Aus dieser Überlegung heraus würde ich das Verzeichnis dem User geben, und den httpd anweisen, die Sachen im Userkontext auszuführen – hierzu wurde suEXEC erfunden.

[TRex]

Es ist eine sinnvolle Sache, die geringstmöglichen Rechte zu nutzen, nicht die maximal Möglichen, wie es sudo code nunmal macht. Aus dieser Überlegung heraus würde ich das Verzeichnis dem User geben, und den httpd anweisen, die Sachen im Userkontext auszuführen – hierzu wurde suEXEC erfunden.

Das würde ich nur empfehlen, wenn ich weiß, was da laufen soll - lass mich auf eine Web-App zugreifen, die die Rechte des Entwicklers hat und dazu verschiedene Sicherheitslücken wie die Möglichkeit, beliebige Dateien zu öffnen oder zu schreiben oder gar etwas auszuführen (direkt oder indirekt). Solange es um lokale, isolierte Entwicklung geht, oder die UID auf dem System sonst keine Bedeutung hat (SSH/SFTP) - okay.

[DeletedUserReAsG]

Solange es um lokale, isolierte Entwicklung geht

Das ist, was ich nun anhand des Eröffnungsbeitrags angenommen habe, ja. Abgesehen davon gibt’s schon noch Möglichkeiten, die Scripte auf das DocumentRoot festzunageln.

[miriki]

würde ich das Verzeichnis dem User geben, und den httpd anweisen, die Sachen im Userkontext auszuführen

Ich bin mir nicht ganz sicher, ob wir hier aneinander vorbei reden, oder ob ich es einfach nur falsch verstehe. Ich geh nochmal "back to square 1".

Auf Debian 11.3.0 läuft Apache2 als httpd (mit mySQL und PHP). Unter /var/www/html/ liegt das Server-Root und von Haus aus eine index.html. Diese und die darunter befindlichen Dirs und Files sind als 644 root:root angelegt, u.a. auch ein miriki/public/, in dem sich eine info.php befindet. (Und die ich als miriki mangels Rechten gar nicht bearbeiten kann...)

Zur Zeit: Ich starte "sudo mc" und kann dann im Server-Root die Datei(en) bearbeiten und auch Unterverzeichnisse anlegen. Diese kriegen dann auch 644 root:root, wenn ich mich nicht irre. Ist ja aber auch kein Problem, da ich ja als root unterwegs bin. Aber eigentlich möchte ich das nicht...

Mein Gedanke: der httpd läuft als www-data laut /etc/apache2/envvars. Als dieser könnte er aber z.Z. auch keine Files verändern (oder neu anlegen), soweit ich weiss, da ja root überall die Hände drauf hat. Alleine von daher würde ich den ganzen Tree dann auf 664 www-data:www-data (oder besser root:www-data ?) umsetzen. Dann kann der httpd Files anlegen und schreiben (eine kleine Datenbank, ein Logfile, ...).

Und dann würde ich meinen realen Benutzer miriki in die Gruppe www-data aufnehmen. Dann kann ich direkt als miriki die Files und Dirs bearbeiten, ohne auf root-Rechte umzuschalten. Edith ergänzt: Egal, ob mit MC-Editor, Nano oder eben auch VS-Vode und Konsorten.

miriki kann auch per vsftpd einloggen und müsste dann auch Files von remote (NotePad++) bearbeiten können.

Ein Script zum Bearbeiten der Files per Web-Browser würde auf dem Debian als www-data laufen und könnte ebenfalls ohne Probleme die Files erreichen, ohne auf root-Rechte zurückgreifen zu müssen.

Und als letztes würde ich dann vielleicht noch das SGID auf das Server-Root (für dann eben die Gruppe www-data) setzen. Oder ist das nicht so gut?

Ist das ganze so (sinnvoll) umsetzbar oder totaler Murks? Oder gibt es eine Alternative, die sinnvoller ist? Der Linux-Rechner ist als "Server" nur im intranet 192.168 erreichbar und da ist auf absehbare Zeit auch nichts Anderes geplant.

Gruß, Michael

[miriki]

Ist das ganze so (sinnvoll) umsetzbar oder totaler Murks?

Da keiner mehr was dazu angemerkt hat, hab ich das dann mal so umgesetzt. Scheint auch soweit zu funktionieren.

Gruß, Michael