Logrotate on mounted partition

Daniel J Walsh dwalsh at redhat.com
Tue Aug 18 17:40:08 UTC 2009


On 08/18/2009 09:41 AM, Arthur Dent wrote:
> On Tue, 2009-08-18 at 13:48 +0200, Dominick Grift wrote:
>> On Tue, Aug 18, 2009 at 12:23:25PM +0100, Arthur Dent wrote:
>>> 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...
> [snip]
>>>>>>> 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
>>>
>>
>> Whoops obviously you need to allow procmail_t to search mountpoints to make it work.
>>
>> echo "> > 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" auditallow -M myprocmail; semodule -i myprocmail.pp
>>
>> this is a bug in policy	
> 
> Thank you Dominick, that's fixed it!
> 
> I had already created a policy module from that AVC just to see what it
> would look like - but I hadn't implemented it. Now I have and it works
> fine!
> 
> BTW, I though your way of creating the module was very clever - I liked
> that.. but for the sake of the archives there are a couple of typos:
> 
> echo "> > 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" auditallow -M 
>                                               ^^^   ^^^
> myprocmail; semodule -i myprocmail.pp
> 
> Should be:
> echo "> > 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" | audit2allow -M
> myprocmail; semodule -i myprocmail.pp
> 
> Thanks again
> 
> Your help is much appreciated!
> 
> Mark
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
I will change rawhide to allow all domains to search mnt_t, since this is a logical place for people to mount directories that a confined application might need access to.

Similarly I will allow all domains to search default_t, which is the default name for a directory created in /






More information about the fedora-selinux-list mailing list