Bug 923927
Summary: | Some dirs are labeled differently in /var/lib/mock directory | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Miroslav Grepl <mgrepl> | ||||||
Component: | mock | Assignee: | Clark Williams <williams> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 19 | CC: | dwalsh, icon, mebrown, pmatilai, williams | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 948396 (view as bug list) | Environment: | |||||||
Last Closed: | 2013-05-04 01:40:29 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 948396 | ||||||||
Attachments: |
|
Description
Miroslav Grepl
2013-03-20 18:08:27 UTC
Actually it looks like it is caused by yum-builddep. If that is being launched by mock, mock was supposed to tell it to not do any labeling. Yes, probably there is a change. *** Bug 835934 has been marked as a duplicate of this bug. *** (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? Mock should not touch the label of the chroot. The idea is to tell rpm/yum not to do any labeling. Panu what is the flag to rpm to tell it not to label content? RPMTRANS_FLAG_NOCONTEXTS, but yum has its own version, both yum and yum-builddep should accept --setopt=tsflags=nocontext on the cli. I'll look at adding the --setopt=tsflags=nocontext option on all yum operations inside mock. 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.
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? I use the default mock setup. Clark does this change effect yum-builddep? Is this run as a separate process and for some reason does not get the flag? (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. 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.
Clark, this is much better. Now I see mock_var_lib_t labeling. I finally got it working in enforcing mode for staff_t. Will update rules. mock-1.1.31-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.31-1.fc19 mock-1.1.31-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mock-1.1.31-1.fc17 mock-1.1.31-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.31-1.el6 mock-1.1.31-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mock-1.1.31-1.fc18 Package mock-1.1.31-1.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 mock-1.1.31-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5858/mock-1.1.31-1.fc19 then log in and leave karma (feedback). mock-1.1.32-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mock-1.1.32-1.fc17 mock-1.1.32-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mock-1.1.32-1.fc18 mock-1.1.32-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.32-1.el6 mock-1.1.32-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mock-1.1.32-1.fc19 mock-1.1.32-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. mock-1.1.32-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. mock-1.1.32-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |