Datenzugriffsrechte immer noch ROT

Deutsches Forum
1

Hi,
ich habe die folgende Verzeichnisse inkl. Unterverzeichnisse auf “777” gesetzt

* /out/pictures/ (recurse into subdirectories)
* /out/media/ (recurse into subdirectories)
* /log/ (recurse into subdirectories)

Was ist bzw. heißt das?

* /out/<sTheme from config.inc.php>/src/ (recurse into subdirectories) (/out/basic/src/ during setup)
    * <sCompileDir from config.inc.php> (recurse into subdirectories) (/tmp/ during setup)

Die Dateien

* /config.inc.php auf 777 gesetzt
* /.htaccess auch auf 777 gesetzt (sie liegt im gleichen Verzeichnis wie die config)

trotzdem leuchtet die “rote Ampel”.

Wer kann hier helfen.

2

Bei der Installation muss /out/basic/src auf 0777 gesetzt sein. Nach der Installation ist aber azure eingestellt. D.h. du musst auch /out/azure/src auf 0777 setzen. Wenn du ein eigenes Theme verwendest musst du entsprechend auch dessen src Verzeichnis anpassen.

3

[QUOTE=burli;55563]Bei der Installation muss /out/basic/src auf 0777 gesetzt sein. Nach der Installation ist aber azure eingestellt. D.h. du musst auch /out/azure/src auf 0777 setzen. Wenn du ein eigenes Theme verwendest musst du entsprechend auch dessen src Verzeichnis anpassen.[/QUOTE]

hab genau dasselbe problem, jedoch hat auch das src-verzeichnis nicht dazu beigetragen, dass sich das icon grün färbt :wink:

4

Oh Ja, da habe ich auch schon geflucht.

folgendes solltest Du machen.

folgende Verzeichnisse und Unterverzeichnisse und Dateien auf 777 setzen:
/tmp/
/log/
/out/azure/src/
/out/basic/src/
/out/media/
out/pictures/

in der Root die beiden Dateien auf 777 setzen
.htaccess
config.inc.php

Wenn die Installation durch ist bekommst Du im Admin wieder diverse Fehlermeldungen.
/setup --> Verzeichniss Löschen

.htaccess
config.inc.php
auf 444 (read only) setzen, dann sollte auch dieser Punkt im Admin auf grün gehen.

5

Hi,

Leute, 777 und 444 sind gefährlich!
Es hängt von der Serverkonfiguration und vom dortigen OS ab, welche Rechte vergeben werden müssen. Es kann gut sein, dass auf einer Suse 755 reicht, während auf einem Debian 777 sein muss. Genauso kann 444 dazu führen, dass nicht mal mehr der FTP-user eine Datei löschen kann. Abhängig vom OS sollte hier 644 vergeben werden.

Gruß

6

[QUOTE=Marco Steinhaeuser;56045]Hi,

Leute, 777 und 444 sind gefährlich!
Es hängt von der Serverkonfiguration und vom dortigen OS ab, welche Rechte vergeben werden müssen. Es kann gut sein, dass auf einer Suse 755 reicht, während auf einem Debian 777 sein muss. Genauso kann 444 dazu führen, dass nicht mal mehr der FTP-user eine Datei löschen kann. Abhängig vom OS sollte hier 644 vergeben werden.

Gruß[/QUOTE]

Dann sollte OXID aber mal ganz fix das in seinem manual zur installation ändern, weil dort steht nämlich auch, dass für htaccess + config 444 vergeben werden soll!

7

[QUOTE=exo;56833]Dann sollte OXID aber mal ganz fix das in seinem manual zur installation ändern, weil dort steht nämlich auch, dass für htaccess + config 444 vergeben werden soll![/QUOTE]

Das ist laut oxid dann aber wieder zu unsicher. Wobei ich persönlich der Meinung bin das sobald einer so weit ist das er auf dem Webserver schreiben kann sowieso jede sicherheitsmaßnahme fehlgeschlagen ist. Zumal das grad bei der config.inc.php großer quark ist, da kann ich nämlich auch die core/oxconfig.php editieren sodass dort nicht die config.inc.php sondern die config.inc.hacked.php eingebunden wird. die confic.inc.php auf 444 macht alles nur umständlich und bringt keine wirklich große zusätzliche sicherheit.

8

habe mir gestern die freie version herunter geladen und auf meinen server hoch geladen (OXID_ESHOP_CE_4.7.3_54408). Nur die Ampel steht immer noch auf rot, trotz rechte vergabe. dieser ordner existiert nicht in meinen Upload “/out/basic/src/”. Debian 6.0 - Plesk 10.2 wird benutzt. Anbieter ist Server4You und PHP-Safe-Mode-Verwaltung ist aus.

9

versuch mal das am Ende hier:

echo $sPathToCheck;
10

Das steht so da drin

        }

        // testing if file permissions >= $iMinPerm
        //if ( ( (int) substr( decoct( fileperms( $sFullPath ) ), 2 ) ) < $iMinPerm ) {
        if ( !is_readable( $sPathToCheck ) || !is_writable( $sPathToCheck ) ) {
            $iModStat = 0;
            break;
        }

und so habe ich Sie geändert

[QUOTE]
// testing if file permissions >= $iMinPerm
//if ( ( (int) substr( decoct( fileperms( $sFullPath ) ), 2 ) ) < $iMinPerm ) {
if ( !is_readable( $sPathToCheck ) || !is_writable( $sPathToCheck ) ) {
checkServerPermissions()$iModStat = 0;
break;
}[/QUOTE

nun bekomme error 500 bzw. Seite bleibt weiss

11 
            // testing if file permissions >= $iMinPerm
            //if ( ( (int) substr( decoct( fileperms( $sFullPath ) ), 2 ) ) < $iMinPerm ) {
            if ( !is_readable( $sPathToCheck ) || !is_writable( $sPathToCheck ) ) {
                $iModStat = 0;
                break;
            }

            $sPathToCheck = next( $aPathsToCheck );
        }
       echo $sPathToCheck;
        return $iModStat;
    }
12

Hat leider nichts gebracht, immer noch rot

13

Ja, natürlich noch rot - aber hast Du im Wiki gelesen, was diese Änderung bewirkt?

14

Tut mir Leid das ich leider kaum Englischkenntnisse habe und php nicht gerade gut bewandert bin, Sorry. Deswegen Frage ich auch in diesen Forum nach Hilfe. So nun meine Frage was muss ich nun machen damit der eshop nun endlich installiert werden kann.

EDIT:
jetzt habe ich es gesehen :wink:

15

so alles installiert lief alles sauber in die Datenbank. Als ich dann testen wollte 500 er error fehler.
Heißt das nun das der Hoster scheiße ist? System ist V-Host

16

War das jetzt zu krass was ich geschrieben habe? Wenn ja, Sorry - so bin ich nun mal wenn mal was nicht funktioniert.Wenn man seit Stunden für eine Einrichtung braucht verliert man schon mal die Fassung.

17

Fehler 500 kann man im Apache Error Log sehen was nicht passt.