Hallo,
ich möchte im webroot eine Datei bearbeiten, die aktuell auf 400 steht.
Die Benutzerrechte lassen sich per SSH als auch über den Datei Manager setzen, jedoch werden diese unverzüglich wieder zurückgesetzt.
Die Datei gehört dem user.
crontab -l zeigt nichts an.
Es gibt keine geplanten Aufgaben.
Hat jemand eine Idee?
Benutzerrechte werden sofort wieder zurückgesetzt [GELÖST]
Re: Benutzerrechte werden sofort wieder zurückgesetzt
OS ist debian, Root Server auf KVM Basis.
Keyhelp aktuelle Version.
Keyhelp aktuelle Version.
Re: Benutzerrechte werden sofort wieder zurückgesetzt
Ich habe die Aufgabe gelöst indem ich eine copy der Datei in ~/files/ bearbeitet und dann zurückgespielt habe.
Dort tritt dieses Problem nicht auf.
Dort tritt dieses Problem nicht auf.
Re: Benutzerrechte werden sofort wieder zurückgesetzt
der Beitrag wurde als gelöst markiert?
Das ist ja eher ein Notbehelf.
Niemand der auch dieses Problem beobachtet hat?
Das ist ja eher ein Notbehelf.
Niemand der auch dieses Problem beobachtet hat?
Re: Benutzerrechte werden sofort wieder zurückgesetzt
Naja, wird irgendwas in deiner Applikation oder sonstigen sein, müsstest einfach mal prüfen ob es beim Aufruf passiert.
Kenne es zB. von gehackten Seiten die bei Aufruf Dateien erstellen oder ändern.
Aber da wird man dir hier wenig helfen können, wenn man es selbst nicht prüfen kann. Du teilst ja auch wenig mit, welche Dateien, welche Rechte, wann es passiert etc. und zum Raten ist das in einem Forum zu anstrengend
Kenne es zB. von gehackten Seiten die bei Aufruf Dateien erstellen oder ändern.
Aber da wird man dir hier wenig helfen können, wenn man es selbst nicht prüfen kann. Du teilst ja auch wenig mit, welche Dateien, welche Rechte, wann es passiert etc. und zum Raten ist das in einem Forum zu anstrengend
Liebe Grüße
Tobias
Tobias
Re: Benutzerrechte werden sofort wieder zurückgesetzt
Guten Morgen,
wie geschrieben passiert das bei der Änderung der Benutzerrechte von Lesen auf Schreiben auf, also logischerweise auf 6xx.
Es handelt sich um eine frontend configure.php, die von der Anwendung nur ausgelesen werden muss.
Ich hatte die Datei nach der Installation der Anwendung vor einem Jahr manuell auf read-only gesetzt.
Hinweise auf einen Hack gibt es nicht, weder in dieser Datei, die nicht manipuliert ist, und weiterhin auf sicheren nur-Lese Rechten steht.
Auch an keiner anderen Stelle gibt es Hinweise auf einen Hack (weder bei Funktion, noch den Logfiles, keine komischen Verzeichnisse und Dateien, Textstrings etc.).
Einen Wechsel auf die Standard Installations- sowie Werbroot-Benutzerrechte 644 könnte ich noch eher verstehen als das Zurücksetzen auf die non-Standard Installations- sowie Webroot-Benutzerrechte "nur lesen".
Es hätte ja sein können, dass jemand etwas aus der Erfahrung heraus dazu sagen kann.
Raten lassen wollte ich natürlich niemanden.
Wird dann wohl an der Anwendung liegen. Werde das jetzt weiter beobachten.
wie geschrieben passiert das bei der Änderung der Benutzerrechte von Lesen auf Schreiben auf, also logischerweise auf 6xx.
Es handelt sich um eine frontend configure.php, die von der Anwendung nur ausgelesen werden muss.
Ich hatte die Datei nach der Installation der Anwendung vor einem Jahr manuell auf read-only gesetzt.
Hinweise auf einen Hack gibt es nicht, weder in dieser Datei, die nicht manipuliert ist, und weiterhin auf sicheren nur-Lese Rechten steht.
Auch an keiner anderen Stelle gibt es Hinweise auf einen Hack (weder bei Funktion, noch den Logfiles, keine komischen Verzeichnisse und Dateien, Textstrings etc.).
Einen Wechsel auf die Standard Installations- sowie Werbroot-Benutzerrechte 644 könnte ich noch eher verstehen als das Zurücksetzen auf die non-Standard Installations- sowie Webroot-Benutzerrechte "nur lesen".
Es hätte ja sein können, dass jemand etwas aus der Erfahrung heraus dazu sagen kann.
Raten lassen wollte ich natürlich niemanden.
Wird dann wohl an der Anwendung liegen. Werde das jetzt weiter beobachten.
Re: Benutzerrechte werden sofort wieder zurückgesetzt [GELÖST]
ich habe jetzt vermutlich den schuldigen gefunden. und zwar verursacht das aufrufen des shop backends diese änderung, die mal als security-patch hinzugekommen war.
In der schlafenden Dev Installation hinter dem Verzeichnisschutz gab es den Fehler erst beim Betreten des Backends.
Weil in der aktiven Shopinstallation im Gegensatz zur Dev alle 15 Sekunden eine whois-online.php ausgeführt wird wurde die zwar fürs frontend zuständige aber natürlich sehr wichtige datei eben ständig hinsichtlich ihrer Benutzerrechte modifiziert.
Also jetzt ists gelöst
In der schlafenden Dev Installation hinter dem Verzeichnisschutz gab es den Fehler erst beim Betreten des Backends.
Weil in der aktiven Shopinstallation im Gegensatz zur Dev alle 15 Sekunden eine whois-online.php ausgeführt wird wurde die zwar fürs frontend zuständige aber natürlich sehr wichtige datei eben ständig hinsichtlich ihrer Benutzerrechte modifiziert.
Also jetzt ists gelöst