Bug 630479 - rebuilds fail with ""execmod" access" errors from SELinux
Summary: rebuilds fail with ""execmod" access" errors from SELinux
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 13
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-05 20:42 UTC by Alex Lancaster
Modified: 2013-01-10 06:11 UTC (History)
3 users (show)

Fixed In Version: mock-1.1.10-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-28 22:22:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alex Lancaster 2010-09-05 20:42:03 UTC
I'm trying to rebuild packages in mock from RPM Fusion and having selinux errors with mock 1.1.4-1.fc13 that weren't present for previous versions of mock with the same package.

The proximate failure of the build (in this case XBMC is attempting to do a configure-time check against xvidcore) are messages like this:

SELinux is preventing /builddir/build/BUILD/xbmc-Dharma_beta1/xbmc/lib/libid3tag/libid3tag/a.out "execmod" access to /usr/lib/libxvidcore.so.4.2

I tracked this down to the fact that builds seem to have mismatched permissions.  The installed version of the library has textrel_shlib:

-rwxr-xr-x. root root system_u:object_r:textrel_shlib_t:s0 /usr/lib64/libxvidcore.so.4.2

versus in the mock-installed version it has var_lib_t:

-rwxr-xr-x. root root unconfined_u:object_r:var_lib_t:s0 /var/lib/mock/fedora-13-x86_64/root/usr/lib64/libxvidcore.so.4.2

This didn't seem to be problem with the builds previously.  Is this an issue with mock, or do the individual packages need to be fixed?

One workaround is to fix the permissions using chcon after the BuildRequires are installed but before the %build starts.  But then I have to fix about 5 or 6 different libraries because other libraries such as libswscale.so.0.11.0 have the same issue.

Comment 1 Alex Lancaster 2010-09-05 20:55:44 UTC
I thought this might be related to bug #573111.

Also I assume that the information in:

http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#Using_mock_under_SELinux

is out of date?  If so, this should be removed from the wiki.  (Note that I did not implement those suggestions in the wiki, I'm using mock unmodified out-of-the-box, but I thought that somebody should probably remove or modify that info if it's no longer relevant).

Comment 2 Alex Lancaster 2010-09-05 21:10:40 UTC
Here's the full selinux message for reference:

Summary:

SELinux is preventing
/builddir/build/BUILD/xbmc-Dharma_beta1/xbmc/lib/libid3tag/libid3tag/a.out
"execmod" access to /usr/lib64/libxvidcore.so.4.2.

Detailed Description:

[conftest has a permissive type (unconfined_notrans_t). This access was not
denied.]

SELinux denied access requested by a.out. /usr/lib64/libxvidcore.so.4.2 may be a
mislabeled. /usr/lib64/libxvidcore.so.4.2 default SELinux type is
textrel_shlib_t, but its current type is var_lib_t. Changing this file back to
the default type, may fix your problem.

File contexts can be assigned to a file in the following ways.

  * Files created in a directory receive the file context of the parent
    directory by default.
  * The SELinux policy might override the default label inherited from the
    parent directory by specifying a process running in context A which creates
    a file in a directory labeled B will instead create the file with label C.
    An example of this would be the dhcp client running with the dhclient_t type
    and creating a file in the directory /etc. This file would normally receive
    the etc_t type due to parental inheritance but instead the file is labeled
    with the net_conf_t type because the SELinux policy specifies this.
  * Users can change the file context on a file using tools such as chcon, or
    restorecon.

This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.

However, this might also indicate a bug in SELinux because the file should not
have been labeled with this type.

If you believe this is a bug, please file a bug report against this package.

Allowing Access:

You can restore the default system context to this file by executing the
restorecon command. restorecon '/usr/lib64/libxvidcore.so.4.2', if this file is
a directory, you can recursively restore using restorecon -R
'/usr/lib64/libxvidcore.so.4.2'.

Fix Command:

/sbin/restorecon '/usr/lib64/libxvidcore.so.4.2'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_notrans_t:s0-
                              s0:c0.c1023
Target Context                unconfined_u:object_r:var_lib_t:s0
Target Objects                /usr/lib64/libxvidcore.so.4.2 [ file ]
Source                        conftest
Source Path                   /builddir/build/BUILD/xbmc-9.11/conftest
Port                          <Unknown>
Host                          allele3.localdomain
Source RPM Packages           
Target RPM Packages           xvidcore-1.2.1-3.fc12
Policy RPM                    selinux-policy-3.7.19-51.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   restorecon
Host Name                     allele3.localdomain
Platform                      Linux allele3.localdomain
                              2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23
                              17:14:44 UTC 2010 x86_64 x86_64
Alert Count                   71
First Seen                    Thu 26 Aug 2010 12:07:05 PM EDT
Last Seen                     Sun 05 Sep 2010 04:52:13 PM EDT
Local ID                      7285cbb9-c4d1-4818-8c1f-359fe214421f
Line Numbers                  

Raw Audit Messages            

node=allele3.localdomain type=AVC msg=audit(1283719933.981:37921): avc:  denied  { execmod } for  pid=13624 comm="a.out" path="/usr/lib64/libxvidcore.so.4.2" dev=dm-0 ino=15612331 scontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file

node=allele3.localdomain type=SYSCALL msg=audit(1283719933.981:37921): arch=c000003e syscall=10 success=yes exit=68719476864 a0=7fe39de3f000 a1=9b000 a2=5 a3=7fe39de42b20 items=0 ppid=13623 pid=13624 auid=501 uid=502 gid=487 euid=502 suid=502 fsuid=502 egid=487 sgid=487 fsgid=487 tty=pts1 ses=2 comm="a.out" exe="/builddir/build/BUILD/xbmc-Dharma_beta1/xbmc/lib/libid3tag/libid3tag/a.out" subj=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 key=(null)

Comment 3 Alex Lancaster 2010-09-06 19:13:37 UTC
I was able to work-around this by adding:

config_opts['plugin_conf']['selinux_enable'] = False

to /etc/mock/site-defaults.cfg.  Not sure if this would be considered a good solution or not.  Did the default change from False to True with mock 1.1.4, perhaps?  Maybe that was why I didn't see the error before.

Comment 4 Clark Williams 2010-10-15 03:19:36 UTC
There's a new build of mock in koji that may solve your problem:

https://koji.fedoraproject.org/koji/buildinfo?buildID=200570

This is mock-1.1.6 for f13 and it has some fixes to the selinux plugin that may fix your SELinux problem. Please give it a try.

Comment 5 Fedora Update System 2010-10-20 15:41:13 UTC
mock-1.1.6-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/mock-1.1.6-1.fc13

Comment 6 Fedora Update System 2010-10-20 15:41:43 UTC
mock-1.1.6-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/mock-1.1.6-1.fc14

Comment 7 Fedora Update System 2010-10-20 15:43:50 UTC
mock-1.0.13-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.13-1.el5

Comment 8 Fedora Update System 2010-10-20 15:46:14 UTC
mock-1.0.13-1.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/mock-1.0.13-1.fc12

Comment 9 Fedora Update System 2010-10-21 05:56:19 UTC
mock-1.1.6-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mock'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/mock-1.1.6-1.fc13

Comment 10 Fedora Update System 2010-10-28 22:21:54 UTC
mock-1.1.6-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2010-11-01 20:58:26 UTC
mock-1.1.6-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2010-12-14 16:14:00 UTC
mock-1.0.14-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.14-1.el5

Comment 13 Fedora Update System 2011-01-18 20:04:12 UTC
mock-1.0.15-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.15-1.el5

Comment 14 Fedora Update System 2011-02-20 02:26:21 UTC
mock-1.1.9-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/mock-1.1.9-1.fc13

Comment 15 Fedora Update System 2011-02-20 02:29:30 UTC
mock-1.0.16-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.16-1.el5

Comment 16 Fedora Update System 2011-02-20 02:32:23 UTC
mock-1.1.9-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.9-1.el6

Comment 17 Fedora Update System 2011-02-20 02:35:15 UTC
mock-1.1.9-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/mock-1.1.9-1.fc14

Comment 18 Fedora Update System 2011-03-03 08:24:58 UTC
mock-1.1.9-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2011-03-03 08:33:50 UTC
mock-1.1.9-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2011-05-13 20:34:03 UTC
mock-1.1.10-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc15

Comment 21 Fedora Update System 2011-05-13 20:38:43 UTC
mock-1.1.10-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc14

Comment 22 Fedora Update System 2011-05-13 20:43:00 UTC
mock-1.0.17-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.17-1.el5

Comment 23 Fedora Update System 2011-05-13 20:47:18 UTC
mock-1.1.10-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc13

Comment 24 Fedora Update System 2011-05-13 20:51:32 UTC
mock-1.1.10-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.el6

Comment 25 Fedora Update System 2011-05-19 04:35:25 UTC
mock-1.1.10-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 Fedora Update System 2011-05-25 02:42:47 UTC
mock-1.1.10-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Fedora Update System 2011-05-25 03:17:09 UTC
mock-1.1.10-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 28 Fedora Update System 2011-06-02 19:06:58 UTC
mock-1.0.17-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2011-06-02 19:16:54 UTC
mock-1.1.10-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.


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