Description of problem: I am seeing lots of AVC messages like the following type=AVC msg=audit(1157304251.270:27): avc: denied { read write } for pid=4176 comm="accton" name="error" dev=dm-0 ino=6259103 scontext=system_u:system_r:acct_t:s0 tcontext=user_u:object_r:mailman_log_t:s0 tclass=file type=SYSCALL msg=audit(1157304251.270:27): arch=40000003 syscall=11 success=yes exit=0 a0=8ecee88 a1=8ecf028 a2=8ecef48 a3=8eced00 items=0 ppid=4156 pid=4176 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="accton" exe="/sbin/accton" subj=system_u:system_r:acct_t:s0 key=(null) These indicate acct is checking if it has { read write } permission on these files that were opened by logrotate. Please make sure you execute fcntl(fd, FD_SETFD, FD_CLOEXEC) To fix the problem
I can't reproduce it on clean FC-6 installation :-(
Created attachment 136743 [details] Closes leaky file descriptors
Daniel, I don't why I can't reproduce any of these AVC bugs(205072,205876). :-( I have looked at your patch and it seems to me there might be cleaner solution. logrotate.c:909 if (!debug) { fd = createOutputFile(log->files[logNum], O_CREAT | O_RDWR, &sb); if (fd < 0) hasErrors = 1; + else + close(fd); } I gonna test it.
Is it necessary to use fcntl( {inFile,outFile}, F_SETFD, FD_CLOEXEC); in situation like this: if (!fork()) { dup2(inFile, 0); close(inFile); dup2(outFile, 1); close(outFile); execvp(fullCommand[0], (void *) fullCommand);
No because you are explictly meaning to leak them in this case. The problem case is when they get leaked unexpectedly.
Created attachment 137033 [details] close fd I think this patch fix the problem. Daniel, could you confirm it?
I am not able to recreate the situation on demand, so apply the patch and I will watch for additional avc messages.
Patch applied in logrotate-3.7.4-6. If problem persist, reopen this bug report.