Hallo, On 08-Feb-2005 Georg Lohrer wrote:

Zitat von Sapheriel :

...

ich würde vermuten, da das meinste davon systemkritische verzeichnisse sind, das root:root standard für diese verzeichnisse ist.

Nein, ist es nicht.

Wie wär's mit:

find /bin -user work -group users -print

um die Dateien zu finden. Und dann für die Änderung

find /bin -user work -group users -exec chown root:root {} \;

Das für jedes der genannten Verzeichnisse. Unter Umständen kannst Du auch noch nach Filetypen 'find -type' unterscheiden. Schau Dir einfach die manpage von find dazu durch.

Das wird das Problem nur verschlimmbessern. Du brauchst doch nur mal in den genannten Verzeichnissen nachzuschauen, um zu sehen, dass es mit root.root nicht getan ist. Einzige Moeglichkeit duerfte sein, Suseconfig mal von Hand aufzurufen und zu hoffen, dass die Rechte dann automatisch wieder richtig gesetzt werden. Frueher bot yast auch mal die Moeglichkeit eines reinstall. Ob es das immer noch gibt, weiss ich nicht. Das waere sonst aber auch noch eine Moeglichkeit. Die systemweiten Konfigurationen gehen dabei zwar verloren, aber die kann man dann ja aus dem Backup einspielen. Beste Gruesse, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/

Hallo David, hallo Sapheriel, hallo Leute, (David, das ist einer der seltenen Fälle, in denen ich Dir widerspreche ;-) Am Dienstag, 8. Februar 2005 20:31 schrieb David Haller:

Am Tue, 08 Feb 2005, Sapheriel schrieb:

...

ich wollte einige dateien zwischen zwei accounts verschieben und hab mich beim verzeichniswechsel vertippt. dann habe ich

chown -R work:users *

in / ausgeführt (ja, ganz genau dort). [...] kann mir einer sagen wie ich am besten vorgehe um alle berechtigungen wieder richtig zu setzen?

/sbin/conf.d/SuSEconfig.permissions

setzt die in /etc/permissions* festgelegten Rechte.

Dann noch ein 'rpm --setugids -a'

Falsche Reihenfolge ;-) Zuerst rpm --setugids und dann SuSEconfig.permissions, da SuSEconfig die Permissions evtl _absichtlich_ anders setzt als im RPM angegeben.

und fuer den Rest ist 'rpm --verify' dein Freund.

Ich würde eher ein find empfehlen, das nach Dateien sucht, die noch work:users gehören. (Der benötigte find-Befehl wurde in diesem Thread ja schon genannt.) Die gefundenen Dateien dann passend per chown zurückändern - oft passt root:root, aber eben nicht immer. Im Zweifelsfall einfach ausprobieren ;-) oder mit den Rechten auf einem anderen Rechner (falls vorhanden) vergleichen. Hintergrund: Es können durchaus Dateien vorhanden sein, die nicht per RPM installiert wurden (z. B. Dateien in /etc/sysconfig) - die werden bei sämtlichen genannten RPM-Befehlen schlicht übersehen und stellen durch die Beschreibbarkeit durch "work" ein Sicherheitsrisiko dar. Gruß Christian Boltz -- "Der Pinguin ist ein gutes Logo für Linux, denn was nicht fliegt, stürzt auch nicht ab." Francis Kuhlen (IBM-Vice President Sales)

Hallo David, hallo Leute, Am Mittwoch, 9. Februar 2005 04:38 schrieb David Haller:

Am Tue, 08 Feb 2005, Christian Boltz schrieb:

...

Hallo David, hallo Sapheriel, hallo Leute,

(David, das ist einer der seltenen Fälle, in denen ich Dir widerspreche ;-)

Schoen, dass es das auch gibt :) Sowas kommt ja nicht allzu oft vor, selbst, wenn ich mich mal in Gebiete begebe, wo ich wenig Ahnung habe.

BTW an alle: ich weiss nicht, wie ich auf die Leser hier wirke, ich kann da nur aus den Mails ableiten, aber wenn ich mal daneben liege, dann will ich korrigiert werden bzw. einen Widerspruch bekommen.

Dein Wunsch sei Dir erfüllt ;-)

...

Am Dienstag, 8. Februar 2005 20:31 schrieb David Haller: [Dateiowner reparieren]

...

/sbin/conf.d/SuSEconfig.permissions

setzt die in /etc/permissions* festgelegten Rechte.

Dann noch ein 'rpm --setugids -a'

Falsche Reihenfolge ;-) Zuerst rpm --setugids und dann SuSEconfig.permissions, da SuSEconfig die Permissions evtl _absichtlich_ anders setzt als im RPM angegeben.

Stimmt.

...

...

und fuer den Rest ist 'rpm --verify' dein Freund.

Ich würde eher ein find empfehlen, das nach Dateien sucht, die noch work:users gehören.

Ack. Also wohl rpm --setugids, dann rpm --verify, dann

Falls man das --verify überhaupt laufen lassen will. Nach einem --setugids dürfte es sowieso keine Fehler bei den Berechtigungen finden ;-) Falls es Dir um mögliche Änderungen an Dateien geht: Wäre ich ein Angreifer, würde ich irgendeine Datei in /etc ändern (z. B. profile.local oder so) und nicht irgendwas in /bin/ oder /usr/bin/. Grund: Unterschiede in /bin/ oder /usr/bin/ fallen sofort auf - schließlich sind das Dateien, die sich "nicht ändern dürfen". Änderungen an Dateien in /etc/ sind dagegen nur mühsam nachzuvollziehen, da dort ja auch bewusst geänderte Configfiles rumliegen. Man müsste also alle geänderten Configfiles von Hand durchgehen, was doch einige Zeit in Anspruch nimmt. Und auf den Zeitstempel kann man sich auch nicht verlassen, da ein gewissenhafter Angreifer immer touch mit einem älteren Datum ausführen würde ;-)

SuSEconfig.permissions und dann das find?

Jepp, die Reihenfolge passt. Was noch work:users gehört, muss auf jeden Fall manuell korrigiert werden (außer /home/work/ ;-)

Oder das --verify doch erst nach dem SuSEconfig?

Das verwirrt eher, da ja SuSEconfig.permissions etliche Dateirechte wieder ändert - diese würden dann angemeckert...

Hm. Wie waere mit sowas wie einem (ungetestet dahingetipperten):

find / -user work -group users -print0 \ | xargs -0 rpm -qf 2>/dev/null

Mit 2>/dev/null unterschlägst Du Dateien, die zu keinem Paket gehören - und die können durchaus kritische Daten enthalten (viele Dateien in /etc/sysconfig/ gehören zu keinem Paket...)

| sort -u | while read pkg; do rpm --verify "$pkg" ## oder gleich 'rpm --setugids "$pkg"' done

Siehe oben - wegen user/group braucht man das --verify nicht mehr. Und wenn man auf Dateiänderungen prüfen will, sollte man es _vor_ dem --setugids machen, damit find die relevanten Dateien auch wirklich findet (nach --setugids gehören die ja wieder root o. a. und fallen durchs Suchraster). Alternativ kann man auch gleich rpm --verify -a nehmen - das überprüft in diesem Fall nur unwesentlich mehr Pakete und man kann sicher sein, dass man nichts übersehen hat ;-)

Das was dann noch ueberbleibt sollte sich durch Raten und/oder anhand eventueller Fehlermeldungen korrigieren lassen ("work.users" in /var/lib/rpm/*? Nee, ich glaub nich ;))

*g* Nochmal zusammengefasst - ich würde ich so vorgehen: rpm --setugids -a rpm --verify -a # angemeckerte Dateien manuell nachprüfen SuSEconfig.permissions find / -user work -group users # gefundene Dateien manuell chown'en

Und nochwas: obiges ist wieder mal ein Beispiel, wie maechtig (wenn auch manchmal scheinbar(!) langsam) die "klassische" Unix-Kommandozeile sein kann :)))

ACK!

Man kann aber ja derweil was anderes machen, z.B. in einem anderen xterm/auf einer anderen Konsole mail oder news lesen *bg*

Wie? Mail auf einer Konsole? Du weißt doch, dass ich meine Mails mit der Maus durch die Gegend schubsen will ;-) *flücht*

Aber Achtung: kann sein, dass ich da "GNUisms" wie das 'find -print0 | xargs -0' und evtl. das '-u' beim 'sort' eingebaut habe (bei Letzterem waere stattdessen 'sort | uniq' zu verwenden).

Da wir ja von SuSE Linux reden, dürfte das kein Problem sein ;-)

...

--

"Der Pinguin ist ein gutes Logo für Linux, denn was nicht fliegt, stürzt auch nicht ab." Francis Kuhlen (IBM-Vice President Sales)

Snarfed! Aber was macht die Leerzeile da?

Die ist mir reingerutscht, weil ich die Sig von Hand gekürzt habe. Im Original ist da ein Männchen dahinter, das den Text auf einem Schild vor sich hält. Nur ist das für eine ML eben ein paar Zeilen zu lang - ich habe es dann manuell weggekürzt und die Leerzeile übersehen ;-) Gruß Christian Boltz --

[Strings in C] Das würde alles nur Aussagen über die glibc erlauben. Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-) [> Thorsten Haude und Jan Trippler in suse-linux]