Mit PHP neuen vHost einfügen? [Archiv] - linuxforen.de -- User helfen Usern

Archiv verlassen und diese Seite im Standarddesign anzeigen : Mit PHP neuen vHost einfügen?

imm0rt4l

03.01.05, 14:20

Hi folks,

kann ich über php irgendwie neue vHosts einfügen?
Müsste doch theoretisch irgendwie möglich sein die httpd.conf
zu editieren, oder wie macht das Confixx oder webmin?

Danke!

Viele Grüße,
imm0rt4l

robotangel

03.01.05, 14:37

Kannst mit PHP ne .htaccess erstellen....

Duke

03.01.05, 14:59

Es sollte mit php theoretisch möglich sein, wenn man einem webbenutzer das Rootdocument wegnimmt und Schreibrechte auf die Apache conf gibst, aber mir wäre das nen bissel zu gefährlich

Ich würde dann schon eher mit php irgendwas erstellen, dass dann per cron mit perl geändert wird

imm0rt4l

03.01.05, 15:01

Ja, würde aber gerne vHosts editieren.
Das mit .htaccess löst mein Problem nicht. :rolleyes:

MrIch

03.01.05, 16:06

ich würde niemals ein php Skript was von außen ist irgendwas am System ändern lassen.

Das einzige was ich mir vorstellen kann ist eine Kombination... ein php Skript schreibt alle Änderungeaufträge in ne Datei und ein Cronjob übernimmt alle 30min die Änderungen ...

Duke

03.01.05, 16:08

cane

03.01.05, 16:09

Das einzige was ich mir vorstellen kann ist eine Kombination... ein php Skript schreibt alle Änderungeaufträge in ne Datei und ein Cronjob übernimmt alle 30min die Änderungen ...

Völlig richtig...

Hat da einer das Linux-Magazin gelesen ;)

mfg
cane

Roger Wilco

03.01.05, 17:54

Völlig richtig...

Hat da einer das Linux-Magazin gelesen ;)

mfg
cane
...oder kennt einfach Confixx...

$kuLL

03.01.05, 18:20

Sowas über cron zu lösen wäre sicher nicht die eleganteste Lösung: stellt euch mal vor ihr müsstest bei Confixx 25 min warten bis eure Änderungen aktiv wären :rolleyes:

Ich habe z.B. eine extra vHosts.conf die einfach included wird. Die httpd.conf wird nie angefasst. Die Datei ist mit den entsprechenden Flags geschützt. Dazu dann ein ShellScript das beliebige vHosts an die vHosts.conf anhängt. Auch das Script ist geschützt (immutable Flag).

Über PHP kann man das Script dann einfach mit den entsprechenden Parametern aufrufen. Natürlich mit den dazugehörigen Sicherungsabfragen.

Das war etwas Brainstorming jetzt, es gibt sicherlich noch andere Lösungen.

Roger Wilco

03.01.05, 18:43

Sowas über cron zu lösen wäre sicher nicht die eleganteste Lösung: stellt euch mal vor ihr müsstest bei Confixx 25 min warten bis eure Änderungen aktiv wären :rolleyes:
Genauso macht es aber Confixx: Jede Minute (!) läuft ein Cronjob, der bei Änderungen ein weiteres Skript aufruft, welches die Änderungen dann durchführt.

$kuLL

03.01.05, 19:22

Ja wie gesagt, viele Wege führen nach Rom.

Aber es entzieht sich mir immer jeglicher Logik, warum ich für eine Aktion die ich im Regelfall sehr selten durchführe, den armen crond minütlich belasten muss. Der hat schließlich auch Gefühle :D

Ich stehe dann eher auf selbst gebastelte On-Demand Lösungen. Aber jedem das seine.

Gruß

cane

04.01.05, 12:31

Aber es entzieht sich mir immer jeglicher Logik, warum ich für eine Aktion die ich im Regelfall sehr selten durchführe, den armen crond minütlich belasten muss.

Aus Sicherheitsgründen - das Script braucht dann keine erweiterten Rechte sondern nur der Cronjob.

mfg
cane

$kuLL

04.01.05, 15:58

Das läuft auf's gleiche hinaus.
Der crond ruft das Scrift dann auch nur mit den Rechten des angebenen Users auf bzw. mit den Rechten dessen User, der den Job erstellt hat.

cane

05.01.05, 15:07

Das läuft auf's gleiche hinaus.
Der crond ruft das Scrift dann auch nur mit den Rechten des angebenen Users auf bzw. mit den Rechten dessen User, der den Job erstellt hat.

Du verstehst da was falsch...

Das Problem ist das wenn ein Script erweiterte Rechte braucht, sagen wir einfach mal es läuft mit gesetztem SUID-Bit, und es sind Fehler im Script dann kann ein Angreifer mit Root-Rechten auf das system zugreifen.

Läuft das Script aber ohne erweiterte Rechte und legt die Eingaben in einer Datei ab kann ein Cronjob der SUID läuft sich die Datei auslesen und die gewünschten Aktionen durchführen.

Es existiert also eine Hürde zwischen Script und cronjob...

mfg
cane

Roger Wilco

05.01.05, 16:43

Das Problem ist das wenn ein Script erweiterte Rechte braucht, sagen wir einfach mal es läuft mit gesetztem SUID-Bit, und es sind Fehler im Script dann kann ein Angreifer mit Root-Rechten auf das system zugreifen.
Die gleiche Problematik hast du aber auch bei einem Cronjob, der die Änderungen durchführt. Wenn du die Eingabe nicht genügend prüfst und bösen[tm] Code filterst, bringt dir auch ein Cronjob nichts.

Läuft das Script aber ohne erweiterte Rechte und legt die Eingaben in einer Datei ab kann ein Cronjob der SUID läuft sich die Datei auslesen und die gewünschten Aktionen durchführen.
Dazu brauche ich aber auch keinen Cronjob. Es genügt auch einfach bei Änderungen ein anderes Programm/Skript aufzurufen, welches sich die notwendigen Rechte mittels sudo oder ähnlichen Mechanismen besorgt.

Ich halte die "On-Demand" Lösung (also das Skript ruft direkt das andere Programm auf, welches die Änderungen in das System übernimmt) für angenehmer und ebenso sicher, da eben kein Cronjob dauernd laufen muss. Das kann je nach Skript und Programmierung den Server unnötig stark belasten.

imm0rt4l

15.02.05, 10:43

Gibt es denn irgendwo Beispiele die man sich anschauen kann um zu verstehen wie das umgesetzt wurde im Netz?

Gruß,
imm0rt4l

Roger Wilco

15.02.05, 13:53

SysCP, Secoto, Webmin. Sind alle im Quellcode erhältlich.