Bug 734137
| Summary: | mock does not recognize group ownership, unable to run mock as unprivileged user | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mertensb |
| Component: | mock | Assignee: | Clark Williams <williams> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | mebrown, williams, yury |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-10-12 19:06:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
mertensb
2011-08-29 14:26:01 UTC
Silly question: did you log out and log back in to make sure that the new group membership took effect? Yes I had. I tried again today after rebooting the machine.
I found out yesterday that the SELinux policy I had compiled was not loaded, so the restorecon command did not have affect.
I fixed that before trying again but it still fails:
[mertensb@localhost ~]$ sudo /usr/sbin/semodule -l|grep mock
[sudo] password for mertensb:
[mertensb@localhost ~]$
[mertensb@localhost ~]$ sudo ls -l /root/selinux.local
total 84
-rw-rw-r-- 1 mertensb mertensb 139 Aug 29 15:36 mock.fc
-rw-rw-r-- 1 mertensb mertensb 1365 Aug 29 15:36 mock.if
-rw-r--r-- 1 root root 48810 Aug 29 15:41 mock.pp
-rw-rw-r-- 1 mertensb mertensb 696 Aug 29 15:36 mock.te
drwxr-xr-x 2 root root 4096 Aug 29 15:41 tmp
[mertensb@localhost ~]$ sudo ls -ldZ /usr/bin/mock /usr/sbin/mock /var/lib/mock/
lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/mock
-rwxr-xr-x root root system_u:object_r:sbin_t /usr/sbin/mock
drwxr-xr-x root mock system_u:object_r:file_t /var/lib/mock/
[mertensb@localhost ~]$ df -h /var/lib/mock
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg1-mock 5.0G 139M 4.6G 3% /var/lib/mock
[mertensb@localhost ~]$ sudo ls -laZ /var/lib/mock/
drwxr-xr-x root mock system_u:object_r:file_t .
drwxr-xr-x root root system_u:object_r:var_lib_t ..
drwx------ root root system_u:object_r:file_t lost+found
[mertensb@localhost ~]$ sudo /usr/sbin/semodule -i /root/selinux.local/mock.pp
[mertensb@localhost ~]$ sudo /sbin/restorecon /usr/bin/mock /usr/sbin/mock /var/lib/mock/
[mertensb@localhost ~]$ sudo ls -ldZ /usr/bin/mock /usr/sbin/mock /var/lib/mock/
lrwxrwxrwx root root system_u:object_r:bin_t /usr/bin/mock
-rwxr-xr-x root root system_u:object_r:sbin_t /usr/sbin/mock
drwxr-xr-x root mock system_u:object_r:mock_var_lib_t /var/lib/mock/
[mertensb@localhost ~]$ sudo ls -laZ /var/lib/mock/
drwxr-xr-x root mock system_u:object_r:mock_var_lib_t .
drwxr-xr-x root root system_u:object_r:var_lib_t ..
drwx------ root root system_u:object_r:file_t lost+found
[mertensb@localhost ~]$ sudo /usr/sbin/semodule -l|grep mock
mock 0.7.1
[mertensb@localhost ~]$
[mertensb@localhost ~]$ su - mock
Password:
[mock@localhost ~]$ /usr/bin/mock --version
ERROR: Must be member of 'mock' group to run mock! ([])
Traceback (most recent call last):
File "/usr/sbin/mock", line 860, in ?
main(retParams)
File "/usr/sbin/mock", line 586, in main
groupcheck()
File "/usr/sbin/mock", line 543, in groupcheck
raise RuntimeError, "Must be member of 'mock' group to run mock! (%s)" % members
RuntimeError: Must be member of 'mock' group to run mock! ([])
[mock@localhost ~]$ id
uid=203(mock) gid=156(mock) groups=156(mock) context=user_u:system_r:unconfined_t
[mock@localhost ~]$
I found that using my own user account the mock --version does work!
So I created another build user, named mockbuild whose primary group is not mock but who is a member of the mock group and this user too is able to display the mock version number. It seems that even though a user must be in the mock group he/she can't have mock as primary group???
But building with mock still fails, there appears to be python > 2.4 code in mock 1.1.11 while python 2.4 is default on this system.
[mertensb@localhost ~]$ sudo /usr/sbin/adduser -u 204 -d /home/mockbuild -c "autobuild user for RHEL packages" -G mock mockbuild
[mertensb@localhost ~]$ id mockbuild
uid=204(mockbuild) gid=204(mockbuild) groups=204(mockbuild),156(mock) context=user_u:system_r:unconfined_t
[mertensb@localhost ~]$ sudo passwd mockbuild
Changing password for user mockbuild.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[mertensb@localhost ~]$ id mock ; id mockbuild
uid=203(mock) gid=156(mock) groups=156(mock),10(wheel) context=user_u:system_r:unconfined_t
uid=204(mockbuild) gid=204(mockbuild) groups=204(mockbuild),156(mock) context=user_u:system_r:unconfined_t
Note: I even added the mock user to the wheel group like my own user but that did not have any effect.
[mockbuild@localhost ~]$ /usr/bin/mock --version
1.1.11
[mockbuild@localhost ~]$ /usr/bin/mock --init -r fedora-15-i386
INFO: mock.py version 1.1.11 starting...
State Changed: init plugins
ERROR: invalid syntax (selinux.py, line 59)
Traceback (most recent call last):
File "/usr/sbin/mock", line 860, in ?
main(retParams)
File "/usr/sbin/mock", line 678, in main
chroot = mock.backend.Root(config_opts, uidManager)
File "<peak.util.decorators.rewrap wrapping mock.backend.__init__ at 0x06D3F398>", line 3, in __init__
def __init__(self, config, uidManager): return __decorated(self, config, uidManager)
File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.4/site-packages/mock/backend.py", line 109, in __init__
self._initPlugins()
File "<peak.util.decorators.rewrap wrapping mock.backend._initPlugins at 0x06D45DE8>", line 3, in _initPlugins
def _initPlugins(self): return __decorated(self)
File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.4/site-packages/mock/backend.py", line 677, in _initPlugins
module = imp.load_module(modname, fp, pathname, description)
File "/usr/lib/python2.4/site-packages/mock/plugins/selinux.py", line 59
with open("/proc/filesystems") as host:
^
SyntaxError: invalid syntax
[mertensb@localhost ~]$ python -V
Python 2.4.3
mock-0.6.13-1.el5_2.3.x86_64.rpm from the CentOS5 extras repository does work for the mockbuild user as well as the mock user! So this appears to be a regression between 0.6.13 and 1.1.11 in the way user permissions are checked and a missing dependency on python >2.4? . Are you running mock-1.1.x on CentOS5? You should be running mock-1.0.x there, since it is setup to run on RHEL5. Possibly we have some dependencies wrong if you got mock 1.1.11 delivered through the epel-5 channel. Yes, this is on CentOS 5.6 [mertensb@localhost ~]$ cat /etc/redhat-release CentOS release 5.6 (Final) But the 1.1 version was from rpmforge, there does nto appear to be a CentOS version of mock. Installed Packages Name : mock Arch : x86_64 Version : 0.6.13 Release : 1.el5_2.3 Size : 99 k Repo : installed Summary : Builds packages inside chroots URL : http://fedoraproject.org/wiki/Projects/Mock License : GPL Description: Mock takes a srpm and builds it in a chroot Available Packages Name : mock Arch : noarch Version : 1.1.11 Release : 1.el5.rf Size : 166 k Repo : rpmforge Summary : Tool to allow building RPM packages in chroots URL : http://fedoraproject.org/wiki/Projects/Mock License : GPLv2+ Description: Mock takes an SRPM and builds it in a chroot [mertensb@localhost ~]$ [mertensb@localhost ~]$ rpm -qi mock Name : mock Relocations: (not relocatable) Version : 0.6.13 Vendor: CentOS Release : 1.el5_2.3 Build Date: Wed 03 Sep 2008 04:13:37 PM CEST Install Date: Tue 30 Aug 2011 10:23:44 AM CEST Build Host: builder10.centos.org Group : Development/Tools Source RPM: mock-0.6.13-1.el5_2.3.src.rpm Size : 101858 License: GPL Signature : DSA/SHA1, Mon 08 Sep 2008 10:09:26 PM CEST, Key ID a8a447dce8562897 URL : http://fedoraproject.org/wiki/Projects/Mock Summary : Builds packages inside chroots Description : Mock takes a srpm and builds it in a chroot [mertensb@localhost ~]$ Look on rpmforge for the highest 1.0.x version of mock. The 1.1.x versions won't run on a RHEL5-based system (such as Centos 5.6). Hi! After the SELinux fix that I upstreamed, our users have reported to be happily running version 1.1.15 on RHEL5. See here for unsigned test packages: http://rpm.zaytsev.net/test/mock/ Of course, we can also add version 1.0.x, but I would be very unhappy to maintain both at the same time as long as 1.1.15 also works on RHEL5, especially now that I almost don't have RHEL5 boxes (apart from old production machines) anymore and can't even test it properly. Z. (In reply to comment #3) > File "/usr/lib/python2.4/site-packages/mock/plugins/selinux.py", line 59 > with open("/proc/filesystems") as host: > ^ > SyntaxError: invalid syntax Ah, I now see from the trace that SELinux was exactly the problem here. Unless there is something else that introduces an incompatibility with RHEL5, my new test packages should work for you. I guess this bug can be closed as a duplicate of this one then: https://bugzilla.redhat.com/show_bug.cgi?id=740327 (In reply to comment #7) > Look on rpmforge for the highest 1.0.x version of mock. The 1.1.x versions > won't run on a RHEL5-based system (such as Centos 5.6). Clark, out of interest, are you planning to make use of Python 2.5+ syntax in mock 1.1.15+ or introduce some deep incompatibilities with RHEL5, or it's just not tested on RHEL5 anymore and therefore understandably not supported? Thanks! (In reply to comment #9) > Clark, out of interest, are you planning to make use of Python 2.5+ syntax in > mock 1.1.15+ or introduce some deep incompatibilities with RHEL5, or it's just > not tested on RHEL5 anymore and therefore understandably not supported? > > Thanks! Yury, I had not planned on making use of 2.5+ syntax (at least until we all decide to switch to Python 3). It's actually looking like I may be able to drop the 1.0.x series used for EPEL5, but I need to confirm that with more testing. *** This bug has been marked as a duplicate of bug 70327 *** Thanks for clearing it up! Much appreciated. Clark, Yury, This bug is now closed as a duplicate of bug 70327 which is about nVidia i810_audio pcitable entry has incorrect format. I guess there was a mixup here, I don't believe these two bugs are related at all. Works for me! (In reply to comment #13) > Works for me! He's right, it should be bug 740327 and not bug 70327 (note the missing '4'). Not that it's a matter of utmost importance, but anyway... |