Re: Logrotate on mounted partition

[Dominick Grift]

On Tue, Aug 18, 2009 at 11:39:07AM +0100, Arthur Dent wrote:
>  On Tue, 2009-08-18 at 11:21 +0200, Dominick Grift wrote:
>  > On Tue, Aug 18, 2009 at 10:12:16AM +0100, Arthur Dent wrote:
>  > > On Sat, 2009-08-15 at 11:50 +0100, Arthur Dent wrote:
>  
>  [snip]
>  
>  > > 
>  > > Just to add to my own mail...
>  > > 
>  > > I employed the above policy module, everything seemed OK so (as this
>  > > seemed to be the last of the problems since upgrading) I switched to
>  > > enforcing mode.
>  > > 
>  > > Since doing so I have received no AVCs but I am finding these in my
>  > > maillog:
>  > > 
>  > > procmail: Lock failure on "/mnt/backup/mail/rawmail.lock"
>  > > procmail: Error while writing to "/mnt/backup/mail/rawmail"
>  > > 
>  > > Temporarily switching back with setenforce 0 stops them so it is selinux
>  > > related...
>  > > 
>  > > 
>  > > Also, I get these dovecot messages (although I haven't investigated
>  > > fully if they are selinux related...
>  > > **Unmatched Entries**
>  > >     dovecot: IMAP(wife): fchown() failed with
>  > > file /home/wife/mail/.imap/INBOX/dovecot.index.tmp: Operation not
>  > > permitted: 1 Time(s)
>  > >     dovecot: IMAP(son): fchown() failed with
>  > > file /home/son/mail/.imap/INBOX/dovecot.index.cache.lock: Operation not
>  > > permitted: 1 Time(s)
>  > >     dovecot: IMAP(son): fchown() failed with
>  > > file /home/son/mail/.imap/INBOX/dovecot.index.log.newlock: Operation not
>  > > permitted: 1 Time(s)
>  > >     dovecot: IMAP(son): fchown() failed with
>  > > file /home/son/mail/.imap/INBOX/dovecot.index.tmp: Operation not
>  > > permitted: 3 Time(s)
>  > >  
>  > > 
>  > > But still no AVCs
>  > > 
>  > > Any ideas?
>  > Try semodule -DB to unload any silent denials. Remember that the denials shown after
> you do this are meant to be silenced.
>  > To reload policy with the silenced denials: semodule -B.
>  > 
>  > Also keep an eye on /var/log/messages since the DBUS user space object manager logs
> some denials there (if DBUS is at all involved)
>  
>  OK - since semodule -DB getting flooded with AVCs...
>  
>  Here are some that are related to this problem...
>  
>  cat /var/log/audit/audit.log | grep -i procmail
>  ....
>  type=AVC msg=audit(1250591203.244:43494): avc:  denied  { rlimitinh }
>  for  pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0
>  tcontext=system_u:system_r:procmail_t:s0 tclass=process
>  type=AVC msg=audit(1250591203.244:43494): avc:  denied  { siginh } for
>  pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0
>  tcontext=system_u:system_r:procmail_t:s0 tclass=process
>  type=AVC msg=audit(1250591203.244:43494): avc:  denied  { noatsecure }
>  for  pid=14767 comm="procmail" scontext=system_u:system_r:sendmail_t:s0
>  tcontext=system_u:system_r:procmail_t:s0 tclass=process
>  type=SYSCALL msg=audit(1250591203.244:43494): arch=40000003 syscall=11
>  success=yes exit=0 a0=5d8098 a1=bf83277c a2=4ab960 a3=41904 items=0
>  ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
>  egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail"
>  exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
>  type=AVC msg=audit(1250591203.418:43495): avc:  denied  { search } for
>  pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921
>  scontext=system_u:system_r:procmail_t:s0
>  tcontext=system_u:object_r:mnt_t:s0 tclass=dir
>  type=SYSCALL msg=audit(1250591203.418:43495): arch=40000003 syscall=196
>  success=no exit=-2 a0=9779280 a1=bf95f790 a2=77cff4 a3=97793f8 items=0
>  ppid=14766 pid=14767 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
>  egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="procmail"
>  exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null)
>  
>  This still with setenforce 0
>  
>  Any ideas?
>  
>  Thanks for your help!...
>  
>  Mark
>   
The only AVC denial that is ( a little bit ) interesting is:

avc:  denied  { search } for
pid=14767 comm="procmail" name="mnt" dev=sda5 ino=943921
scontext=system_u:system_r:procmail_t:s0
tcontext=system_u:object_r:mnt_t:s0 tclass=dir
 
Pipe this into audit2why to see if it has any suggestions. Although i doubt it is related
to your issue.

A quick way to rule out SELinux as the cause of your issue is to reproduce the issue in
permissive mode.

If access is (still) denied when you try to reproduce it in permissive mode, than it is
not an SELinux issue.

If it works in permissive mode, but not in enforcing mode, then it is a SELinux issue.

>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list