Description of problem: When I try to use mock inside a sudo environment, I get permission denied when mock tries to create the result directory. I assume this is because the wrong UID (i.e. the saved UID instead of the effective UID). Version-Release number of selected component (if applicable): git version of 18th feb. 2008 How reproducible: user@host:~> sudo /sbin/mock -r fedora-7-i386 init user must not be in group mock, root is in this group Actual results: State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init ERROR: Could not create dir /var/lib/mock//fedora-7-i386/result. Error: [Errno 13] Permission denied: '/var/lib/mock//fedora-7-i386/result' Traceback (most recent call last): File "/lib64/python2.5/site-packages/mock/util.py", line 38, in mkdirIfAbsent os.makedirs(dirName) File "/usr/lib64/python2.5/os.py", line 172, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/var/lib/mock//fedora-7-i386/result' ERROR: Could not create dir /var/lib/mock//fedora-7-i386/result. Error: [Errno 13] Permission denied: '/var/lib/mock//fedora-7-i386/result' Expected results: Well, not permission denied of course. Additional info:
Try adding root to the mock group (e.g. usermod -G mock root) and see if that fixes things. It looks like the error your seeing is us returning EPERM because you're running as a user not in the mock group.
If you are not in the 'mock' group, use the --resultdir= arg to put the results elsewhere. The /var/lib/mock has perms so that 'mock' group can write there, but nobody else. It always initializes the result dir as the original calling user to avoid unpriv users overwriting system files.
User root is in group mock, the user calling sudo is not. Seems to me that mock somehow uses either the saved UID or the SUDO_UID to determine file access. user@host:/> sudo /sbin/mock -r fedora-7-i386 init INFO: mock.py version 0.8.16 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init ERROR: Could not create dir /var/lib/mock//fedora-7-i386/result. Error: [Errno 13] Permission denied: '/var/lib/mock//fedora-7-i386/result' Traceback (most recent call last): File "/lib64/python2.5/site-packages/mock/util.py", line 38, in mkdirIfAbsent os.makedirs(dirName) File "/usr/lib64/python2.5/os.py", line 172, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/var/lib/mock//fedora-7-i386/result' ERROR: Could not create dir /var/lib/mock//fedora-7-i386/result. Error: [Errno 13] Permission denied: '/var/lib/mock//fedora-7-i386/result' user@host:/> grep mock /etc/group mock:x:55435:root
By the way, when I use ssh root@localhost to change my UID instead of sudo, everything works fine: host:~ # /sbin/mock -r fedora-7-i386 init INFO: mock.py version 0.8.16 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot INFO: enabled yum cache ...
This is acting exactly as designed and intended. You dont have permissions as "user" to anything in the /var/lib/mock/ directory *unless* you are in the 'mock' group. When you are "root", you can do whatever you want and create directories under /var/lib/mock. Mock was written very carefully to try to avoid any regular user from being able to overwrite system directories. It does this by using the permissions of the calling user when creating the resultdir. This avoids letting the user run "mock --resultdir=/etc", or similar badness. So, as stated in #3 above, either (A) add the user to the 'mock' group, or (B) use the --resultdir= argument to put the result directory somewhere where 'user' has permissions.