Bug 734137 - mock does not recognize group ownership, unable to run mock as unprivileged user
Summary: mock does not recognize group ownership, unable to run mock as unprivileged user
Keywords:
Status: CLOSED DUPLICATE of bug 70327
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-29 14:26 UTC by mertensb
Modified: 2011-10-13 14:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-12 19:06:17 UTC


Attachments (Terms of Use)

Description mertensb 2011-08-29 14:26:01 UTC
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?

Comment 1 Clark Williams 2011-08-29 15:22:36 UTC
Silly question: did you log out and log back in to make sure that the new group membership took effect?

Comment 2 mertensb 2011-08-30 06:59:53 UTC
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 ~]$

Comment 3 mertensb 2011-08-30 07:04:40 UTC
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

Comment 4 mertensb 2011-08-30 07:31:21 UTC
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? .

Comment 5 Clark Williams 2011-09-23 18:19:59 UTC
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.

Comment 6 mertensb 2011-09-26 07:22:44 UTC
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 ~]$

Comment 7 Clark Williams 2011-09-26 14:00:26 UTC
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).

Comment 8 Yury V. Zaytsev 2011-09-28 07:48:55 UTC
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.

Comment 9 Yury V. Zaytsev 2011-09-28 07:54:38 UTC
(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!

Comment 10 Clark Williams 2011-10-12 19:06:17 UTC
(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 ***

Comment 11 Yury V. Zaytsev 2011-10-12 21:41:03 UTC
Thanks for clearing it up! Much appreciated.

Comment 12 mertensb 2011-10-13 06:19:04 UTC
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.

Comment 13 Clark Williams 2011-10-13 14:23:38 UTC
Works for me!

Comment 14 Yury V. Zaytsev 2011-10-13 14:29:51 UTC
(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...


Note You need to log in before you can comment on or make changes to this bug.