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.