Re: Permission denied during rpm installation

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

 



On Fri, 2006-07-28 at 22:52 +0800, Deepak Shrestha wrote:
> looking for "avc:", I found lots of entries with "denied" in /var/log/messages
> 
> the entry is rather long so posting only the fragment (hope this will
> still make the point). Its is something like this
> ==============
> Jul 24 23:39:53 webcomp kernel: audit(1153755580.824:2): avc:  denied
> { getattr } for  pid=1153 comm="mount" name="kcore" dev=proc
> ino=-268435435 scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file
> Jul 24 23:39:54 webcomp kernel: audit(1153755580.856:3): avc:  denied
> { getattr } for  pid=1153 comm="mount" name="kcore" dev=proc
> ino=-268435435 scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file
> Jul 25 11:45:16 webcomp kernel: audit(1153799116.610:8): avc:  denied
> { use } for  pid=2467 comm="bluez-pin" name="[7581]" dev=pipefs
> ino=7581 scontext=user_u:system_r:bluetooth_helper_t:s0
> tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
> Jul 25 11:45:16 webcomp kernel: audit(1153799116.610:9): avc:  denied
> { use } for  pid=2467 comm="bluez-pin" name="[7581]" dev=pipefs
> ino=7581 scontext=user_u:system_r:bluetooth_helper_t:s0
> tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
> Jul 25 14:00:21 webcomp kernel: audit(1153807221.327:4): avc:  denied
> { use } for  pid=2291 comm="bluez-pin" name="[7243]" dev=pipefs
> ino=7243 scontext=user_u:system_r:bluetooth_helper_t:s0
> ......
> ......
> ......
> ......
> ..... and so on
> ==============
> 
> What does this mean??? and most importantly why? and what is the solution?

Those particular messages don't look related to your rpm installation
problems; look for avc messages with rpm_t or rpm_script_t in the
scontext or tcontext fields.

If you can narrow down what permission denials are relevant, you can
generate a local policy module that allows them as a temporary
workaround for your own use and file a bugzilla to get them added to the
base policy in a future update.

audit2allow can be used to generate policy from audit messages, but you
want to carefully review the result.  See 
http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385
and the audit2allow man page.

-- 
Stephen Smalley
National Security Agency


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux