Pretty straightforward: type=AVC msg=audit(1315979064.478:125461): avc: denied { read } for pid=26788 comm="spamd" name="shadow" dev=vda2 ino=264049 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1315979064.478:125461): avc: denied { open } for pid=26788 comm="spamd" name="shadow" dev=vda2 ino=264049 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=AVC msg=audit(1315979064.482:125462): avc: denied { getattr } for pid=26788 comm="spamd" path="/etc/shadow" dev=vda2 ino=264049 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file Note that I had to turn dontaudit off to see these. -Robin
I don't think these AVC causes spamd fails. So spamd doesn't work in enforcing mode and if you switch to permissive then spamd works but without AVC msgs?
I don't think they cause fails either, but I haven't looked all that hard, and spamd is fairly robust to errors; it could be failing to perform a particular check but otherwise succeeding. Which doesn't mean you want to allow this necessarily; this was a "just FYI" sort of thing; struck me as worth mentioning. -Robin
But still I don't know it the spamd works for you in enforcing mode or not?
Spamd should definitely not be trying to read the /etc/shadow file. Does this use the pam stack somehow?
Sorry about that. Yes, it totally works even if it can't open /etc/shadow. I can give you an strace of the two cases if you care. -Robin
Ok Do you know if it is using the pam stack? I guess we can dontaudit the access.
I don't know, no. If you can tell me how to figure that out, I'll look. The access already is dontaudit; I said that at the beginning. Sorry, I didn't mean to waste people's time like this. -Robin