[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Logrotate on mounted partition



On Tue, 2009-08-18 at 12:46 +0200, Dominick Grift wrote:
> 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.
> 

Well all that audit2why suggests for that avc is:

	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this
access.

On your other point, you will notice (further up in this mail) that this
problem is only in Enforcing mode. Switching to Permissive does indeed
stop the procmail errors.

Still watching the avcs.... I'll keep you posted..

Thanks

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]