Bug 801871 - spice-xpi cannot create .spicec and write to folder (SeLinux blocks)
Summary: spice-xpi cannot create .spicec and write to folder (SeLinux blocks)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: spice-xpi
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Hatina
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-09 17:23 UTC by Pavel Zhukov
Modified: 2016-06-01 01:31 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-19 14:55:51 UTC
Type: ---


Attachments (Terms of Use)

Description Pavel Zhukov 2012-03-09 17:23:58 UTC
Description of problem:
SELinux is preventing /usr/lib64/xulrunner-2/plugin-container from add_name access on the directory spice-xpi.log.

Version-Release number of selected component (if applicable):
spice-xpi-2.7-1.fc17.x86_64
xulrunner-10.0.1-3.fc17.x86_64


How reproducible:
Enable selinux in enforce mode.

I have created ~/.spicec and change content to mozilla_plugin_t but problem still persists

Additional Information:
Source Context                unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
                              0.c1023
Target Context                unconfined_u:object_r:mozilla_plugin_t:s0
Target Objects                spice-xpi.log [ dir ]
Source                        plugin-containe
Source Path                   /usr/lib64/xulrunner-2/plugin-container
Port                          <Unknown>
Host                          fedora17.home.zhukoff.net
Source RPM Packages           xulrunner-10.0.1-3.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-95.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     fedora17.home.zhukoff.net
Platform                      Linux fedora17.home.zhukoff.net
                              3.3.0-0.rc5.git3.1.fc17.x86_64 #1 SMP Wed Feb 29
                              21:22:11 UTC 2012 x86_64 x86_64
Alert Count                   4
First Seen                    Fri 09 Mar 2012 09:17:59 PM MSK
Last Seen                     Fri 09 Mar 2012 09:18:27 PM MSK
Local ID                      3f756c74-2be6-4a29-b67f-8b175e8550b8

Raw Audit Messages
type=AVC msg=audit(1331313507.530:167): avc:  denied  { add_name } for  pid=2827 comm="plugin-containe" name="spice-xpi.log" scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_t:s0 tclass=dir


type=SYSCALL msg=audit(1331313507.530:167): arch=x86_64 syscall=open success=no exit=EACCES a0=7fc946cfbb18 a1=441 a2=1a4 a3=7fffc352d540 items=0 ppid=2327 pid=2827 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=3 comm=plugin-containe exe=/usr/lib64/xulrunner-2/plugin-container subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)

Comment 1 Marc-Andre Lureau 2012-03-09 18:21:19 UTC
spice-xpi 2.8 will no longer use ~/.spicec.

I just sent an additional patch to Spice ML making sure we don't touch this anymore.

We should release a 2.8 version for f17.

Comment 2 Miroslav Grepl 2012-04-04 14:09:30 UTC
Did you setup your own label?

It looks so. The mozilla_plugin_t label is for process. Just run 

$ restorecon -R -v ~/

It should fix your issue.

Comment 3 Ian Pilcher 2012-06-19 14:21:52 UTC
(In reply to comment #1)
> spice-xpi 2.8 will no longer use ~/.spicec.
> 
> I just sent an additional patch to Spice ML making sure we don't touch this
> anymore.
> 
> We should release a 2.8 version for f17.

NOTABUG doesn't seem like the correct status for this.  It certainly is a bug (in either spice-xpi or the SELinux policy).

And spice-xpi 2.8 doesn't appear to actually exist yet.  (I can find no evidence of it in Koji or on spice-space.org.)  Please don't close bugs until the fix is available.

Comment 4 Ian Pilcher 2012-06-19 14:55:51 UTC
Aargh!  I glossed over comment #2, because I had not set manually set any contexts in my home directory.  Nonetheless, the context of ~/.spicec was the problem.  (Note to self: 'restorecon -r *' is not the same as 'restorecon -r .')

Nothing to see here.  Move along.


Note You need to log in before you can comment on or make changes to this bug.