CHMOD 777 auf / gesetzt --- Hilfe

[DEBA-Xnet]

Hallo,

also ich wollte Shares im Netzwerk writeable machen, und nachdem ich das geschafft habe, habe ich mir gedacht weshalb jedes einzelne Share und nicht das komplette Stammverzeichniss im Netzwerk schreibbar machen... Ein schwerer Fehler...
Folgende 3 Befehle habe ich ausgeführt.

find / -type d -exec chmod 777 {} \;
find / -type f -exec chmod 777 {} \;
chmod 777 /

Danach konnte ich mich als Benutzer in der Konsole nicht mehr als su anmelden und jede administrative GUI verweigerte ihren Dienst mit der Meldung: SU meldet Fehler.

Nach einigen Stunden googeln wurde mir klar, dass dies an der Rechtevergabe hängt...
Dann habe ich folgende Befehle ausgeführt.

find / -type d -exec chmod 4755 {} \;
find / -type f -exec chmod 4755 {} \;
chmod 4755 /

Mit dem Ergebniss, dass ich mich als User nicht mal mehr grafisch einloggen kann, da im homeverzeichniss keine Schreibrechte für .kdeuthority vorliegen.
Anschließend habe ich folgendes ausgeführt:

find /home -type d -exec chmod 777 {} \;
find /home -type f -exec chmod 777 {} \;
chmod 777 /home

Ohne Veränderung.
Gibt es eine Möglichkeit die Standard Rechte zu laden, wieder herzustellen?
Oder kann ich von meinem System irgendwie ein Backup (treiber, appz, einstellungen, etc.) machen, dass ich nach einer neuinstallation aufspielen kann, ohne die Schreibrechte wieder zu crashen?

System Suse 10.3 Kernel 2.6.22.17-0.1

PS. Bei Antworten bitte berücksichtigen das ich ein relativer Linux-Newbie bin

 

[sim4000]

Da Hilft nur den Virtuellen Hammer auf das System zu Hauen.
Zu Deutsch: Formatieren und neu Installieren.

Das war jedenfalls die Antwort bei einem Thread mit dem selben Thema den wir hier mal hatten...

 

[gropiuskalle]

Oder kann ich von meinem System irgendwie ein Backup (treiber, appz, einstellungen, etc.) machen, dass ich nach einer neuinstallation aufspielen kann, ohne die Schreibrechte wieder zu crashen?

Die Reihenfolge ist nicht ganz richtig; erst ein backup anlegen, dann den Mist bauen.

 

[Gott_in_schwarz]

Laut Rain_Makers Antwort in dem bereits erwähnten Thread scheint es aber eventuell nicht völlig verloren. Aber kA, ich kenn mich mit rpm nicht aus. Weiß also auch nicht was dieses "--setperms" jetzt genau macht. Neuaufsetzen ist wohl letztlich der Weg mit weniger Kopfschmerzen.. (Glaub ich, kA. Es äußere sich der Regenmacher.)

 

[supersucker]

Gibt es eine Möglichkeit die Standard Rechte zu laden, wieder herzustellen?
Oder kann ich von meinem System irgendwie ein Backup (treiber, appz, einstellungen, etc.) machen, dass ich nach einer neuinstallation aufspielen kann, ohne die Schreibrechte wieder zu crashen?

Ich würde neu installieren.

Alternativ (aber ohne jede Garantie) kannst du dir das hier zunutze machen:

8.4 --setperms - Setzt die Dateirechte
Wir haben in unserem System ein Paket installiert, bei der Arbeit auf dem System wurden die Dateirechte von Dateien dieses Paketes verändert. Mit dieser Option können die Dateirechte des Paketes wieder auf die Rechte gesetzt werden, welche in der RPM-Datenbank gespeichert sind - diese wurden vom Paketbauer vorgegeben. Schauen wir uns dies an einem Beispiel an:

Wir haben das Paket test installiert. Jetzt verändern wir die Dateirechte einer Datei aus diesem Paket:

# rpm -qlv test

# rpm -qlv test
-rw-r--r-- root root 6Feb 01 19:22 /usr/local/test1
-rw-r--r-- root root 5Feb 01 19:22 /usr/local/test2
# chmod g+w /usr/local/test2
# ls -l /usr/local/test2
-rw-rw-r-- 1 root root 5Feb 1 1999 /usr/local/test2
#



Wir verwenden nun das Kommando rpm --setperms test; wir sehen, daß die Rechte der Datei, auf den Wert aus der Datenbank gesetzt wurden.

# rpm --setperms test
# ls -l /usr/local/test2
-rw-r--r-- 1 root root 5Feb 1 1999 /usr/local/test2

Das heißt du könntest das so probieren:

rpm --setperms `rpm -qa`

Könnte funktionieren.

P.S.:

Das diese Aktion reichlich unintelligent war weißt du ja mittlerweile.

Merke: Im Gegensatz zu Windows haben Rechte unter Linux einen Sinn (und vor allem Auswirkungen aufs System). So don't f**k with 'em!

 

[codc]

Das System ist im Sack und auch kein rpm kann die kompletten Rechte zurücksetzen. Betrachte es als "Lehrgeld" und setz die Kiste neu auf. In /home kann man die Rechte manuell setzen also macht hier ein Backup noch einen Sinn aber alles andere kannst du vergessen.

 

[death]

Hallo,
meinem Kollegen ist das selbe passiert:

su
chmod 777 -R datei1 / datei2

Ich konnte das System wieder einigermaßen retten.

Habe den PC mit einer Live-CD gestartet und dann das Root-Verzeichnis eines zweiten system-identischen PCs über nfs gemountet.

Dann noch das ROOT-verzeichnis des beschädigten PC gemountet und die Verzeichnisse
/bin /sbin /usr/bin /opt etc ....
mit
rsync -avpog /quelle /ziel
synchronisiert.

Jetzt scheint wieder alles zu funktionieren.
Werde aber das System trotzdem neu aufsetzen (aus Sicherheitsgründen) und so manche Probleme werden würden vielleicht erst noch auftauchen.

 

[tuxlover]

da fällt mir gerade was ein; was sogesehen ein feature ist, was mich bei suse nervt, weil ich deshalb jedesmal clamv manuell starten darf, aber in deinem fall nützlich sein könnte:

bei opensuse gibt es in yast --> sicherheit doch so ein tool (name weiß ich jetzt grad net), welches die grundlegenen system-datei rechte regelt. dort einfach mal nach paranoid stellen und dann übernehmen klicken, dann wieder zurücksetzen auf normal und es müsste eigentlich wieder alles richtig sein.

aber ist nur sone idee. ob das klappt kannst du ja dann mal berichten.

grüße tuxlover

 

[sim4000]

Ich glaube nicht, das der Herr sich hier noch mal meldet...

 

[DEBA-Xnet]

Zum ersten... Danke für die Antworten
und zum zweiten... Oh doch ich melde mich.
Ich hab die Vorschläge beherzigt und neu installiert.
Da ich jedoch den radikalen Weg wähle um von Windows wegzukommen (Sprich kein Windows mehr auf meinem Rechner), und nach dem Online Update meine WLAN Karte nicht mehr verfügbar war, habe ich ein wenig Zeit gebraucht um wieder Online zu kommen.
Das Problem ist, fahr ich zweigleisig, schaffe ich nie den kompletten Umstieg, weil ich bei jedem scheinbar unlösbaren Problem wieder auf Windows zurückgreife.

Diesbezüglich noch ein Tipp, für leute die das selbe Problem haben. (Madwifi nach Update)

Nach einem Online Update wird der Kernel ebenfalls geupdatet (von v 2.6.22.5 zu derzeit v 2.6.22.17-0.1). Im neuen Kernel gibt es das file .config im /lib/[Kernel]/build/ nicht mehr.
Dadurch lässt sich der Tarball von madwifi 0.9.4 nicht mehr compilieren.
Ich habe mir alle RPMs von hier gezogen und installiert. Danach hat es gefunzt.

 

[kbdcalls]

Ist das jetzt ein Seuche ?

 

[tuxlover]

ich habe am wochende etwas ganz ähnliches gehabt: aus irgendeinem nicht empfindelichen grund hat ein mir unbekanntes prescript beim installieren eines rpms mir auch als user zugriffsrechte auf sbin verschafft.

nach längeren überlegen habe ich folgendes heruasgefunden:

für alle die die openuse 10.x verwenden (bei anderen versionen bzw. distris weiß ich es nicht genau), gibt es da ein rpm das permissons heißt und zum basissystem gehört.es enthält unter anderem folgende dateien:

/etc/permissions
/etc/permissions.easy
/etc/permissions.paranoid
/etc/permissions.secure

diese kann man auch editieren. so habe ich etwa in allen dateien eingetragen:

/dev/dazuko                root:dazuko              655

um das nicht jedesmal von hand tun zu müssen.

mittels

chkstat -set /etc/permissions
chkstat -set /etc/permissions.secure

lassen sich dann die wichtigsten berechtigungen ganz einfach wieder herstellen.

liebe grüße vom sonnendeck

tuxlover