Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 948396 - Some dirs are labeled differently in /var/lib/mock directory
Summary: Some dirs are labeled differently in /var/lib/mock directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 923927
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-04 17:16 UTC by Miroslav Grepl
Modified: 2013-04-19 05:56 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 923927
Environment:
Last Closed: 2013-04-19 05:56:29 UTC
Type: Bug


Attachments (Terms of Use)

Description Miroslav Grepl 2013-04-04 17:16:24 UTC
+++ This bug was initially created as a clone of Bug #923927 +++

Description of problem:

I see some dirs are labeled differently in /var/lib/mock directory. For example


drwxr-xr-x. root root system_u:object_r:usr_t:s0 /var/lib/mock/fedora-rawhide-x86_64/root/usr/share/yum-cli
drwxr-xr-x. root root system_u:object_r:usr_t:s0 /var/lib/mock/fedora-rawhide-x86_64/root/usr/share/yum-plugins
drwxr-xr-x. root root system_u:object_r:etc_t:s0       logrotate.d
drwxr-xr-x. root root system_u:object_r:etc_t:s0       yum

Version-Release number of selected component (if applicable):

# rpm -q mock selinux-policy
mock-1.1.29-1.fc19.noarch
selinux-policy-3.12.1-22.fc19.noarch

How reproducible:

mock -r fedora-rawhide-x86_64 -v --rebuild selinux-policy-3.12.1-22.fc19.src.rpm


Basically if you change default labeling for /usr/share/yum-cli for example, you get this labeling also in /var/lib/mock/fedora-rawhide-x86_64/root/usr/share/yum-cli.

So does mock setup it using a reference?

--- Additional comment from Miroslav Grepl on 2013-03-20 14:31:25 EDT ---

Actually it looks like it is caused by yum-builddep.

--- Additional comment from Daniel Walsh on 2013-03-20 16:59:44 EDT ---

If that is being launched by mock, mock was supposed to tell it to not do any labeling.

--- Additional comment from Miroslav Grepl on 2013-03-21 04:03:27 EDT ---

Yes, probably there is a change.

--- Additional comment from Miroslav Grepl on 2013-03-21 04:49:49 EDT ---

*** Bug 835934 has been marked as a duplicate of this bug. ***

--- Additional comment from Clark Williams on 2013-03-26 13:47:31 EDT ---

(In reply to comment #2)
> If that is being launched by mock, mock was supposed to tell it to not do
> any labeling.

Couple of questions:

1) should mock explicitly relabel the contents of a chroot? if so what would be the recommendation for how best to do so when setting up a chroot?

2) if mock should just leave the labeling alone, how to tell yum* to do that?

--- Additional comment from Daniel Walsh on 2013-03-26 15:48:09 EDT ---

Mock should not touch the label of the chroot.   The idea is to tell rpm/yum not to do any labeling.

--- Additional comment from Daniel Walsh on 2013-03-26 15:52:57 EDT ---

Panu what is the flag to rpm to tell it not to label content?

--- Additional comment from Panu Matilainen on 2013-03-26 23:50:00 EDT ---

RPMTRANS_FLAG_NOCONTEXTS, but yum has its own version, both yum and yum-builddep should accept --setopt=tsflags=nocontext on the cli.

--- Additional comment from Clark Williams on 2013-03-27 11:13:30 EDT ---

I'll look at adding the --setopt=tsflags=nocontext option on all yum operations inside mock.

--- Additional comment from Clark Williams on 2013-03-27 13:15:58 EDT ---

Created attachment 717173 [details]
Add default options for yum to avoid SELinux relabeling

Added the option '--setopt=tsflags=nocontext' to the yum_common_opt configuration variable, meaning this option will be passed to yum in all yum operations done by mock. 

Testing showed no ill effects so queuing this for the 1.1.30 release.

--- Additional comment from Clark Williams on 2013-03-27 17:10:41 EDT ---

Well, I started seeing duplicate --setopt lines and realized that the selinux plugin alreadys appends --setopt=tsflags=nocontext to yum commands

So, if selinux is running on the host system and the selinux plugin for mock is loaded, it should be passing in the nocontext argument to yum.

Miroslav, you didn't disable the mock selinux plugin did you?

--- Additional comment from Miroslav Grepl on 2013-03-28 02:24:20 EDT ---

I use the default mock setup.

--- Additional comment from Daniel Walsh on 2013-03-28 04:50:56 EDT ---

Clark does this change effect yum-builddep?  Is this run as a separate process and for some reason does not get the flag?

--- Additional comment from Clark Williams on 2013-04-01 15:11:24 EDT ---

(In reply to comment #13)
> Clark does this change effect yum-builddep?  Is this run as a separate
> process and for some reason does not get the flag?

I was just looking at that and yes, I believe there's a case where it can happen. Here's the callback in the selinux.py plugin that does the work:

    def _selinuxDoYum(self, command, *args, **kargs):
        option = "--setopt=tsflags=nocontexts"

        if type(command) is list:
            if command[0] == self.rootObj.yum_path:
                command.append(option)
        elif type(command) is str:
            if command.startswith(self.rootObj.yum_path):
                command += " %s" % option

        return self._originalUtilDo(command, *args, **kargs)


Note the list block that looks for equality with yum_path. That will fail for yum-builddep, while the str block will succeed because of the "startswith" comparison. I'll look into it a bit more but I may need to rework this some.

--- Additional comment from Clark Williams on 2013-04-01 15:16:39 EDT ---

Created attachment 730396 [details]
patch to selinux plugin to catch yum-builddep

Trying this patch to catch invocations of yum-builddep and pass it the 
--setopt=tsflags=nocontexts flag.

--- Additional comment from Miroslav Grepl on 2013-04-04 10:50:33 EDT ---

Clark,
this is much better. Now I see mock_var_lib_t labeling.

--- Additional comment from Miroslav Grepl on 2013-04-04 13:15:41 EDT ---

I finally got it working in enforcing mode for staff_t. Will update rules.

Comment 1 Miroslav Grepl 2013-04-05 09:03:35 UTC
Fixed in selinux-policy-3.12.1-26.fc19

Comment 2 Fedora Update System 2013-04-08 11:44:24 UTC
selinux-policy-3.12.1-28.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2013-5045/selinux-policy-3.12.1-28.fc19

Comment 3 Fedora Update System 2013-04-08 15:56:54 UTC
Package selinux-policy-3.12.1-28.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-28.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5045/selinux-policy-3.12.1-28.fc19
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2013-04-19 05:56:31 UTC
selinux-policy-3.12.1-28.fc19 has been pushed to the Fedora 19 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.