Description of problem: I have set up a build user as described on http://fedoraproject.org/wiki/Projects/Mock#Build_User. Running /usr/sbin/mock to get the help, usage and version information works: [mock@localhost ~]$ /usr/sbin/mock --version 1.1.11 But an unprvileged user is not permitted to run mock: [mock@localhost ~]$ /usr/sbin/mock --init -r fedora-15-i386 ERROR: [Errno 1] Operation not permitted ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user. ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem. However running /usr/bin/mock fails: [mertensb@localhost ~]$ id uid=500(mertensb) gid=500(mertensb) groups=10(wheel),156(mock),500(mertensb) context=user_u:system_r:unconfined_t [mertensb@localhost ~]$ su - mock Password: [mock@localhost ~]$ id uid=203(mock) gid=156(mock) groups=156(mock) context=user_u:system_r:unconfined_t [mock@localhost ~]$ ll /usr/sbin/mock /usr/bin/mock lrwxrwxrwx 1 root root 13 Aug 29 14:17 /usr/bin/mock -> consolehelper -rwxr-xr-x 1 root root 36844 Jul 19 21:55 /usr/sbin/mock [mock@localhost ~]$ /usr/sbin/mock --help |head -1 usage: [mock@localhost ~]$ /usr/bin/mock --help |head -1 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 ~]$ python Python 2.4.3 (#1, May 5 2011, 16:39:10) [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os,grp >>> for g in os.getgroups(): ... name = grp.getgrgid(g).gr_name ... print name ... mock >>> [mock@localhost ~]$ [mock@localhost ~]$ ll -d /var/lib/mock/ drwxr-xr-x 3 root mock 4096 Aug 29 14:14 /var/lib/mock/ [mock@localhost ~]$ ll -dZ /var/lib/mock/ drwxr-xr-x root mock system_u:object_r:file_t /var/lib/mock/ [mock@localhost ~]$ rpm -V mock .M...... /var/lib/mock [mock@localhost ~]$ echo $PATH /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/mock/bin The user is member of the mock group, the python tests return the correct group information when run directly. Perhaps the consolehelper tool is masking the group ownership?
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...