fedora update ändert dateirechte?

[caspartroy]

hallo,

ich habe bei fedora core 4 und 5 erlebt, dass plötzlich ein mailserver nicht mehr funktioniert hat, weil er dateien nicht anlegen darf, und zwar in /var/{spool,run...}
da jede nacht das automatische yum-update läuft, könnte es wohl daran liegen?
oder muss ich damit rechnen, dass ein einbrecher da war? geklaut wurde jedenfalls nichts ;-) und man sollte erwarten, dass die dateirechte nach einbruch weniger restriktiv sind als vorher?

die skripte in /etc/init.d funktionieren im fall von fedora core 5 auch nicht mehr, auch hier das problem wohl dateizugriffsrechte.

betroffen sind clamd, amavisd und sendmail.
habe die rechte überprüft, und bei manuellem start als entsprechender user (amavis im falle von amavisd) funktioniert es auch, ebenso für clamd und sendmail.
nutze übrigens selinux, daran könnte es liegen, aber warum funktioniert es bei manuellem start?

[shogun]

Versuch doch mal, was passiert, wenn Du SELinux abschaltest.
Nur um die Fehlerquelle zu lokalisieren.

[caspartroy]

danke, blöd von mir, dass ich nicht drauf gekommen bin...
ist aber ziemlich blödsinnig, es hatte mit selinux bestens funktioniert und anscheinend wurde da etwas verpatcht...
jedenfalls liegts an selinux und das nervt...


type=AVC msg=audit(1149881808.305:18037): avc: denied { connectto } for pid=28321 comm="amavisd" name="clamd.sock" scontext=root:system_r:amavis_t:s0 tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=unix_stream_socket

offensichtlich ist der (oder das?) socket "unconfined_t",das ist wohl falsch, weiss jemand, was richtig wäre?
sollte das init skript den kontext ändern?

ach und was mir gerade aufgefallen ist: warum geht es, wenn ich von hand starte?

[caspartroy]

habs nochmal angeschaut, wenn ich amavisd von hand starte, erbt clamd.sock die (passenden) rechte, wenn amavisd mit dem init skript gestartet wird, bekommt clamd.sock falsche rechte...
der socket wird aber nicht im init skript angelegt, zumindest bleibt grep -i sock stumm.