On Thursday 05 March 2009, Paul Howarth wrote: >Gene Heskett wrote: >> On Thursday 05 March 2009, Gene Heskett wrote: >>> On Wednesday 04 March 2009, Gene Heskett wrote: >>>> Greetings; >>>> >>>> And a portion of this lists archive on this box has gone missing to >>>> boot. So I can't look up the command to extract all these hits, about >>>> once every 2 minutes or so, to a logfile I can post. And when I click >>>> on the star, it tells me the connection has been lost to >>>> /var/run/setroubleshoot/setroubleshoot_server. But there is a zero >>>> length file there, generated when I rebooted to 2.6.29-rc7 5:18 ago WTH? >>>> >>>> And I just found a very short setroubleshooter.log which I will attach. >>>> It looks like it got a tummy ache just a few minutes ago. >>>> >>>> I think I will follow what I did with 29-rc7, and not build any sound >>>> modules for anything except the audigy2, cuz now I have sound, akonadi >>>> even starts! >>>> >>>> Help? >>> >>> No comment. Can anyone tell me why, when looking at the log messages, >>> and it tells me to get the full report by running sealert with -l >>> hashnumber, I as root am denied? From a root shell: >>> [root@coyote log]# sealert -l 1ed4cefd-aa3b-4727-b9ef-28b8e2cbb42c >>> failed to connect to server: Connection refused >>> >>> I am back on a 2.6.28.7 kernel now. And setroubleshooter's screen alerts >>> in time with the kmail pongs of new mail coming are contributing to my >>> loss of sanity or whatever. Somehow it has decided that fetchmail isn't >>> supposed to be able to access its users directory/.f, uhh, I was gonna >>> run it and get the exact file and the connection to its server has been >>> lost, again. I thought it was funny that the reject messages were going >>> into the system log... >>> >>> Uptodate Fedora 10. x86_64 running 32 bit. >>> >>> A 'service setroubleshoot restart' restarts it though. Anybody have a >>> clue, I seem to be fresh out, and I'm about to compile it out. >> >> Ok, the restart allowed me to collect the most recent hit from sealert: >> =============================== >> [root@coyote init.d]# sealert -l 2ada4c61-64cb-40d7-8268-83488b12426e >> >> Summary: >> >> SELinux is preventing procmail (procmail_t) "append" to >> /var/log/fetchmail.log (var_log_t). >> >> Detailed Description: >> >> [SELinux is in permissive mode, the operation would have been denied but >> was permitted due to permissive mode.] >> >> SELinux is preventing procmail (procmail_t) "append" to >> /var/log/fetchmail.log (var_log_t). The SELinux type var_log_t, is a >> generic type for all files in the directory and very few processes >> (SELinux Domains) are allowed to write to this SELinux type. This type of >> denial usual indicates a mislabeled file. By default a file created in a >> directory has the gets the context of the parent directory, but SELinux >> policy has rules about the creation of directories, that say if a process >> running in one SELinux Domain (D1) creates a file in a directory with a >> particular SELinux File Context (F1) the file gets a different File >> Context (F2). The policy usually allows the SELinux Domain (D1) the >> ability to write, unlink, and append on (F2). But if for some reason a >> file >> (/var/log/fetchmail.log) was created with the wrong context, this domain >> will be denied. The usual solution to this problem is to reset the file >> context on the target file, restorecon -v '/var/log/fetchmail.log'. If the >> file context does not change from var_log_t, then this is probably a bug >> in policy. Please file a bug report >> (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the >> selinux-policy package. If it does change, you can try your application >> again to see if it works. The file context could have been mislabeled by >> editing the file or moving the file from a different directory, if the >> file keeps getting mislabeled, check the init scripts to see if they are >> doing something to mislabel the file. >> >> Allowing Access: >> >> You can attempt to fix file context by executing restorecon -v >> '/var/log/fetchmail.log' >> >> Fix Command: >> >> restorecon '/var/log/fetchmail.log' >> >> Additional Information: >> >> Source Context system_u:system_r:procmail_t:s0 >> Target Context system_u:object_r:var_log_t:s0 >> Target Objects /var/log/fetchmail.log [ file ] >> Source procmail >> Source Path /usr/bin/procmail >> Port <Unknown> >> Host coyote.coyote.den >> Source RPM Packages procmail-3.22-22.fc10 >> Target RPM Packages >> Policy RPM selinux-policy-3.5.13-46.fc10 >> Selinux Enabled True >> Policy Type targeted >> MLS Enabled True >> Enforcing Mode Permissive >> Plugin Name mislabeled_file >> Host Name coyote.coyote.den >> Platform Linux coyote.coyote.den 2.6.28.7 #6 SMP >> PREEMPT Wed Mar 4 23:08:30 EST 2009 i686 athlon Alert Count >> 63 >> First Seen Sat Feb 28 16:34:21 2009 >> Last Seen Thu Mar 5 02:20:43 2009 >> Local ID 2ada4c61-64cb-40d7-8268-83488b12426e >> Line Numbers >> >> Raw Audit Messages >> >> node=coyote.coyote.den type=AVC msg=audit(1236237643.658:745): avc: >> denied { append } for pid=8712 comm="procmail" >> path="/var/log/fetchmail.log" dev=sda3 ino=23527557 >> scontext=system_u:system_r:procmail_t:s0 >> tcontext=system_u:object_r:var_log_t:s0 tclass=file >> >> node=coyote.coyote.den type=SYSCALL msg=audit(1236237643.658:745): >> arch=40000003 syscall=11 success=yes exit=0 a0=8941670 a1=8941748 >> a2=8940af8 a3=0 items=0 ppid=2784 pid=8712 auid=4294967295 uid=501 gid=501 >> euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) >> ses=4294967295 comm="procmail" exe="/usr/bin/procmail" >> subj=system_u:system_r:procmail_t:s0 key=(null) >> >> Thanks Guys. > >Is this a fetchmail log or a procmail log? What do you expect to get >logged here? fetchmails normal activities > >I guess you're running fetchmail in daemon mode with procmail as local >delivery agent? Correct. > >See if this helps: > ># semanage fcontext -a -t procmail_log_t '/var/log/fetchmail\.log' ># restorecon -v /var/log/fetchmail.log > >Paul. I did the restorecon -v thing on the two logs and that seems to have satisfied setroubleshoot. For the nonce, I have had to restart it twice since rebooting last night. I wonder if the f10 upgrade from f8 removed some stuff I had in logrotate to address that? Here are the messages snip surrounding the last failure: Mar 5 02:28:31 coyote setroubleshoot: [program.ERROR] audit event#012node=coyote.coyote.den type=AVC msg=audit(1236238110.422:761): avc: denied { signull } for pid=8602 comm="setroubleshootd" scontext=unconfined_u:unconfined_r:setroubleshootd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 tclass=process#012#012node=coyote.coyote.den type=SYSCALL msg=audit(1236238110.422:761): arch=40000003 syscall=37 success=yes exit=0 a0=1027 a1=0 a2=b7ab8a28 a3=1027 items=0 ppid=1 pid=8602 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="setroubleshootd" exe="/usr/bin/python" subj=unconfined_u:unconfined_r:setroubleshootd_t:s0 key=(null) Mar 5 08:29:46 coyote setroubleshoot: [rpc.ERROR] attempt to open server connection failed: Connection refused Mar 5 08:30:50 coyote setroubleshoot: [server.ERROR] cannot start systen DBus service: org.freedesktop.DBus.Error.AccessDenied: An SELinx policy prevents this sender from sending this message to this recipient (rejected message had interface "org.freedesktop.DBus" member "ello" error name "(unset)" destination "org.freedesktop.DBus") Mar 5 08:31:20 coyote kernel: [33498.076923] SELinux: Context unconfined_u:unconfined_r:setroubleshootd_t:s0- s0:c0.c1023 would be invald if enforcing Chuckle, note miss-spelling above. :) In those cases where I have restarted setroubleshoot, it always reports a failure of the stop action only. Is the above enough to determine an exit reason. In one case earlier, it said "exiting to prevent recursion" As for the logging fsckups, I have now added a few lines to /etc/logrotate.d/mail, as follows. ================= # Logrotate file for fetchmail.log and procmail.log /var/log/fetchmail.log { missingok compress notifempty weekly size=1000k rotate 5 copytruncate create 0600 gene gene prerotate /usr/bin/killall fetchmail sleep 1 endscript postrotate chown gene:gene /var/log/fetchmail.log restorecon -v /var/log/fetchmail.log <-new echo "log rotated on "date -u >>var/log/fetchmail.log su gene -c "/usr/bin/fetchmail -d 90 --fetchmailrc /home/gene/.fetchmailrc" endscript } /var/log/procmail.log { missingok compress notifempty weekly size=1000k rotate 5 copytruncate create 0600 gene gene postrotate restorecon -v /var/log/procmail.log <-new echo "log rotated on "date -u >>/var/log/procmail.log endscript } =============================== logrotates actions have consistently been a PIMA here. Humm, in fact since those two files are 0600 gene gene, should I do an "su gene -c" wrapper on those two restorecon lines? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) For large values of one, one equals two, for small values of two. -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
