Habe als Superuser alle Unix-Dateien auf Recht 700 (schreib/lese/ausführen für Eigentümer) gesetzt.
D.h. alle Unix-Dateien (ausnahmslos alle) wurden auf diese Rechtestruktur gebracht. Wobei root als Eigentümer aller Dateien gesetzt wurde.
Nun hat sich herausgestellt, dass viele Dienste nicht mehr ordnungsgemäß funktionierten. Also habe ich alle Dateien auf 777 gesetzt. Darauf hin gingen wieder einige Dienste doch viele Befehle gehen nicht mehr.
Frage1:
Gibt es eine Funktion (Befehl) der die ursprünglichen Rechte der Dateien wieder herstellt?
Denn selbst die großzügig angelegte Rechtevergabe führt zu Problemen.
Frage2:
Ist es überhaupt sinnvoll an den Voreinstellungen bzgl. Rechte herumzuschrauben oder wird die Sicherheitsbestimmung anders geregelt?
Denn meine Intension die hinter der ganzen Sache gesteckt hat ist, dass ein User der sich einloggt, nur einen gewissen Pool an Befehlen benutzen darf und nur einen bestimmten Bereich von Dateien sehen darf. Wenn bspw. der User „vi /etc/smb.conf“ angibt, kann er die smb.conf sehen aber nicht schreiben. Ich möchte jedoch erreichen, dass der User weder schreiben noch lesen kann. Er darf nicht auf diese Datei zugreifen können (weder schreiben noch lesen noch ausführen).
Im voraus Danke
xxx
Hallo!
Habe als Superuser alle Unix-Dateien auf
Recht 700 (schreib/lese/ausführen für
Eigentümer) gesetzt.
Oh je.
D.h. alle Unix-Dateien (ausnahmslos alle)
wurden auf diese Rechtestruktur gebracht.
Wobei root als Eigentümer aller Dateien
gesetzt wurde.
Also, root ist owner aller dateien. Die Gruppe ist bestimmt auch auf root bei allen Dateien?
Nun hat sich herausgestellt, dass viele
Dienste nicht mehr ordnungsgemäß
funktionierten. Also habe ich alle
Dateien auf 777 gesetzt. Darauf hin
gingen wieder einige Dienste doch viele
Befehle gehen nicht mehr.
Viele Dienste haben ja einen eigenen user (zB ftp oder man), damit sie nicht als root im System rumfuhrwerken.
Frage1:
Gibt es eine Funktion (Befehl) der die
ursprünglichen Rechte der Dateien wieder
herstellt?
Sowas kenne ich nicht. Is vermutlich so wie der rm Befehl. Weg is weg. Aber versuch mal ein Update. Also zB von SuSE6.3 auf SuSE6.4 vielleicht bringts das?
Denn selbst die großzügig angelegte
Rechtevergabe führt zu Problemen.
Das verstehe ich allerdings nicht. Vielleicht checken die Dienste, ob sie owner sind. Und wenn nicht spucken sie.
Frage2:
Ist es überhaupt sinnvoll an den
Voreinstellungen bzgl. Rechte
herumzuschrauben oder wird die
Sicherheitsbestimmung anders geregelt?
Denn meine Intension die hinter der
ganzen Sache gesteckt hat ist, dass ein
User der sich einloggt, nur einen
gewissen Pool an Befehlen benutzen darf
und nur einen bestimmten Bereich von
Dateien sehen darf. Wenn bspw. der User
„vi /etc/smb.conf“ angibt, kann er die
smb.conf sehen aber nicht schreiben. Ich
möchte jedoch erreichen, dass der User
weder schreiben noch lesen kann. Er darf
nicht auf diese Datei zugreifen können
(weder schreiben noch lesen noch
ausführen).
Ja dann setzte doch die Rechte für sensible Daten einzeln und versuch dann immer zu probieren, ob danach noch alles geht.
Denn selbst die großzügig angelegte
Rechtevergabe führt zu Problemen.
Das verstehe ich allerdings nicht.
Vielleicht checken die Dienste, ob sie
owner sind. Und wenn nicht spucken sie.
Ja, zum Beispiel fetchmail streikt, wenn alle Leute die conf-Datei (mit allen Passwörtern!) lesen können…
S.
Hi
Aehnliches Thema: Unter Unixgurus gab und gibt es sehr viele Geschichten die sich um die Anwendung des Befehls:
rm -rf . \*
drehen. Eigentlich wollten diese Leute alle versteckten Dateien, und Verzeichnisse im aktuellen Verzeichniss loeschen. Durch das Leerzeichen zwischen Punkt und Stern, werden aber !! ohne Abfrage !! ALLE Dateien des Systems geloescht. Wenn du diesen Befehl als Root ausfuehrst, bist du erledigt. Als normaler User loescht du nur alle deine eigenen Dateien, wenig beruhigend, aber kleinere Katastrophe.
Dieses Beispiel sollte zeigen, dass es ziemlich oft passt, wie das System aussieht, und das man lieber die Finger von der Tastatur lassen sollte, wenn man mal ne gute Idee hat. 
BTW, bei dir hilft nur mehr eine Neuinstallation. Herumprobieren fuehrt unter gar keinem Umstand zum Ziel. Das einzige was mir einfallen wuerde ist entweder linuxconf, oder fsck.ext2 ausfuehren, die pruefen beide Rechtesettings.
CU
P.S.: Der richtige Loeschbefehl lautet:
rm -rf .[^.]\*
Danke für die Antwort
Zuerst einmal DANKE!!! an *ALLE* die sich die Mühe gemacht haben auf meine Frage eine Antwort zu finden.
Nun zu Tipp eins: „System überspielen“
Habe ich gemacht (genau: von SUSE 6.3 auf 6.4) und alle Rechte wurden wieder hergestellt.
è Folge: alles war wieder voll funktionsfähig!
Bin jetzt jedoch mit dem Thema Sicherheit auf Dateien genauso weit wie vorher.
Nun habe mir ein Script erstellt, dass alle Dateien auf Other-„Rechtseite“ einschränkt,
genau:
keinen lese,
keinen schreib und
keinen ausführe Zugriff.
Diesmal bin ich jedoch her gegangen und habe nicht via chmod 770 /…/… alle Dateien verändert, sondern via chmod o= /…/… .
Dies hat den Vorteil, dass die Dateienrechte auf User und Group Seite nicht verändert werden.
Dann habe ich noch alle Verzeichnisse auf o=x gesetzt. Dies ist wichtig, auch wenn sich der Client nicht via. Bsp. telnet einloggen möchte.
Des weiteren mussten im /dev/ Verzeichnis einige Verzeichnisse und devices als rw gesetzt werden!
Als Erfahrungsbericht kann ich sagen, dass auf meinem System alles funktioniert.
-> Keine Probleme!
Aber als Anmerkung: ich habe aber nur ein MinimalSystem laufen (Firewall + ISDN + Netzwerkarte).
Eine solche Dateienrechteeinschränkung hat bspw. auf einem LinuX-Rechner der als Proxy-Server (Squid) diente nicht funktioniert. Hier musste ich einige Dateien auf für other zugänglich machen.
Resüme: eine Möglichkeit aber mit Vorsicht zu genießen und sehr selektiv zu verwenden.
P.S.: Die SuSE-Hotline konnte mir bis auf eine Person bzgl. dieses Problems nicht weiterhelfen (8 Wahlversuche). Der Rat dieser Person war, dass eine solche Rechteeinschränkung für others nur auf einige wichtige Dateien erfolgen sollte.
Kleine Kritik: das Call-Center wurde zwar ausgebaut, aber die Quantität ist nicht gleich Qualität.
Vielen Dank nochmals
xxx