Moin,

in unregelmäßigen Abständen bekomme ich nach dem Rechte-reparieren mit dem Festplattendienstprogramm folgende Meldung:

Zugriffsrechte für „HD“ reparieren
Korrekte Zugriffsrechte für die Dateien bestimmen
Die Zugriffsrechte für „./private/var/log/secure.log“ unterscheiden sich, Soll-Wert „-rw------- “, Ist-Wert „-rw-r----- “
Eigentümer und Gruppe wurden für „./private/var/log/secure.log“ korrigiert
Zugriffsrechte wurden für „./private/var/log/secure.log“ korrigiert

Reparatur der Zugriffsrechte abgeschlossen
Die Zugriffsrechte wurden auf dem ausgewählten Volume überprüft oder repariert.

Irgendwer neulich hier hatte die gleiche Fehlermeldung, ging aber wohl in dem Thread (anderes Thema) unter, daher hier noch mal meine Frage: Wer oder was will sich hier (ohne den großen, unbekannten X-Virus beschwören zu wollen) immer wieder Lese-Rechte auf secure.log verschaffen? Wie bekomme ich das raus?

Aha, den @@ link hatte ich damals über google nicht gefunden, nun aber über onlinks.com

Um das dann auch gleich mal aufzuklären: Es scheint sich um einen Bug zu handeln, der seit auf jeden Fall 10.4.4 besteht:

>> Dito hier:
>> -rw-r----- 1 root admin 1580 Feb 9 14:17 /var/log/secure.log
>> krass...


So, kurz nachgedacht. Da das bei allen auftritt, aber anscheinend nach
gewissen Regeln, also sozusagen _periodisch_:


grep -r secure /etc/periodic/*

Wahnsinn! Die Routine zum Rotieren der Log-Dateien enthält halt tatsächlich:

touch "${i}" && chmod 640 "${i}" && chown root:admin "${i}"

Wer spielt Kasperle und schreibt den Bug-Report? Ich hab keine Lust mehr,
weil ich eh nur Sicherheitsrelevantes bei Apple abkippe und man von dem
Laden auch bei solchen Sachen monatelang einfach gar keine Antwort bekommt.

Hmpf.

Diese Zugriffsrechte werden verändert von@@(periodic) weekly

touch "${i}" && chmod 640 "${i}" && chown root:admin "${i}"



Abhilfe

touch "${i}" && if [ "${i}" == "secure.log" ]; then chmod 600 "${i}"; else chmod 640 "${i}"; fi && chown root:admin "${i}"

Aber das ist keine dauerhafte Abhilfe, oder? Denn das weekly setzt die Rechte doch mit dem nächsten Durchlauf wieder um?

Ersetze in 500.weekly

die oben angegebene obere Zeile durch die untere;-)

 Eigentlich sollte man sich fragen, warum ein Admin das secure.log nicht einsehen soll/darf

weekly scheint mir daher logischer in der Rechtevergabe als das BaseSystem.pkg

lsbom /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom | grep '\./private/var/log'
./private/var/log       40755   0/0
./private/var/log/apache2       40755   0/0
./private/var/log/caldavd       40755   93/93
./private/var/log/fax   40755   0/0
./private/var/log/ipfw.log      100640  0/80    0       4294967295
./private/var/log/lastlog       100640  0/80    0       4294967295
./private/var/log/ppp   40755   0/0
./private/var/log/sa    40755   0/0
./private/var/log/samba 40755   0/0
./private/var/log/secure.log    100600  0/80    0       4294967295
./private/var/log/uucp  40755   4/0
./private/var/log/wtmp  100644  0/80    0       4294967295

  Wäre der 'bug'; wenn es denn einer ist,
 nicht eher hier zu tilgen?


Ja, und ein report ist schon länger unterwegs zu

_mäuschenAdmins sind auf OS X sudo-berechtigt. Sie können daher alles einsehen.

... und mit Console.app sieht man secure.log auch problemlos (als Admin).

soso:-/

Das stimmt nicht ganz.

Nach Zugriffsrechte reparieren @@ Kein Zugriff

Erst nachdem der weekly job gelaufen(devil)
kann der Admin ohne Umschweife das secure.log ansehen


Erst nachkontrollieren, bevor posten;-)