Rebooted, permissive, setroubleshooter going nuts.

[Gene Heskett]

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?

[Gene Heskett]

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.

[Gene Heskett]

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.

[Paul Howarth]

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?

I guess you're running fetchmail in daemon mode with procmail as local 
delivery agent?

See if this helps:

# semanage fcontext -a -t procmail_log_t '/var/log/fetchmail.log'
# restorecon -v /var/log/fetchmail.log

Paul.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?
>
> I guess you're running fetchmail in daemon mode with procmail as local
> delivery agent?
>
> See if this helps:
>
> # semanage fcontext -a -t procmail_log_t '/var/log/fetchmail.log'
> # restorecon -v /var/log/fetchmail.log
>
> Paul.
>
> -- 
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Currently f10 policy has

./policy/modules/services/mta.te:logging_append_all_logs(system_mail_t)
./policy/modules/system/init.te:logging_append_all_logs(initrc_t)
./policy/modules/system/init.te:logging_append_all_logs(daemon)

I think it could be argued that we should allow all confined domains to
append to any log file, since simple redirection of stdout causes the
AVC in question.  Being able to write to a log file allows a cracked
program to erase the log contents.  Being able to append to a log file
means you could fill up the system with garbage or write something to a
log file that would cause some other app  or Human to do something bad.

Fetchmail policy does not allow for the creation of a logfile right now.
  I guess the default is to write to syslog.  We need to add a mechansim
for fetchmail to create a fetchmail_log_t and allow procmail_t to append
to it.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmv1JIACgkQrlYvE4MpobMVoQCbBguw0NgYBYr0X/6gfv5pqNXF
> IUQAoNW3KmkesnPbo5CcPaUxCofKvPeR
> =TiT3
> -----END PGP SIGNATURE-----

[Miroslav Grepl]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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?
> >
> > I guess you're running fetchmail in daemon mode with procmail as local
> > delivery agent?
> >
> > See if this helps:
> >
> > # semanage fcontext -a -t procmail_log_t '/var/log/fetchmail.log'
> > # restorecon -v /var/log/fetchmail.log
> >
> > Paul.
> >
> > -- 
> > fedora-selinux-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
> Currently f10 policy has
>
> ./policy/modules/services/mta.te:logging_append_all_logs(system_mail_t)
> ./policy/modules/system/init.te:logging_append_all_logs(initrc_t)
> ./policy/modules/system/init.te:logging_append_all_logs(daemon)
>
> I think it could be argued that we should allow all confined domains to
> append to any log file, since simple redirection of stdout causes the
> AVC in question.  Being able to write to a log file allows a cracked
> program to erase the log contents.  Being able to append to a log file
> means you could fill up the system with garbage or write something to a
> log file that would cause some other app  or Human to do something bad.
>
> Fetchmail policy does not allow for the creation of a logfile right now.
>   I guess the default is to write to syslog.  We need to add a mechansim
> for fetchmail to create a fetchmail_log_t and allow procmail_t to append
> to it.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmv1JIACgkQrlYvE4MpobMVoQCbBguw0NgYBYr0X/6gfv5pqNXF
> IUQAoNW3KmkesnPbo5CcPaUxCofKvPeR
> =TiT3
> -----END PGP SIGNATURE-----

Ok, I will add this mechanism to the policy.

[Gene Heskett]

On Thursday 05 March 2009, Daniel J Walsh wrote:
> 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?
> >
> > I guess you're running fetchmail in daemon mode with procmail as local
> > delivery agent?
> >
> > See if this helps:
> >
> > # semanage fcontext -a -t procmail_log_t '/var/log/fetchmail.log'
> > # restorecon -v /var/log/fetchmail.log
> >
> > Paul.
> >
> > --
> > fedora-selinux-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
> Currently f10 policy has
>
> ./policy/modules/services/mta.te:logging_append_all_logs(system_mail_t)
> ./policy/modules/system/init.te:logging_append_all_logs(initrc_t)
> ./policy/modules/system/init.te:logging_append_all_logs(daemon)
>
> I think it could be argued that we should allow all confined domains to
> append to any log file, since simple redirection of stdout causes the
> AVC in question.  Being able to write to a log file allows a cracked
> program to erase the log contents.  Being able to append to a log file
> means you could fill up the system with garbage or write something to a
> log file that would cause some other app  or Human to do something bad.
>
> Fetchmail policy does not allow for the creation of a logfile right now.

fetchmail itself cannot create the file either, it must exist.

Which is why my logrotate "mail" script, posted in another message, uses the 
copytruncate method of pruning the file(s).  I had to touch these originally, 
and chown etc them.  And I have now added the restorecon -v directive also.
However that is running as root I assume, so should I wrap those two lines
in an "su gene -c"?
> I guess the default is to write to syslog.

I believe the default only writes a log if a logfile is defined in the 
matching ~/.fetchmailrc or ~/.procmailrc, otherwise they are silent.
> We need to add a mechansim
> for fetchmail to create a fetchmail_log_t and allow procmail_t to append
> to it.

I think so, Daniel. Something along those lines anyway would certainly reduce 
the noise.  OTOH, maybe my solution in the logrotate.d/mail file is 
sufficient.

But I have NDI exactly when it will trigger a logrotation again.  ATM, trying 
to debug rules, I have procmail set verbose so its noisy as can be with one 
incoming mail generating log entries larger than the usual 1 or 2 paragraph 
mail itself.

[Gene Heskett]

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?