+++ 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.