Bug 980244

Summary: Wrong (r600) permissions on rpm db files - mock builds failed
Product: [Fedora] Fedora Reporter: Anton Guda <atu>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: cleech, mebrown, nphilipp, williams
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-07 22:03:51 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:
Attachments:
Description Flags
Dirty hack - but a working workaround none

Description Anton Guda 2013-07-01 20:33:59 UTC 
Description of problem:
During package build via mock errors occurred, connected to wrong (0600) permissions of rpmdb files. 


Version-Release number of selected component (if applicable):
mock-1.1.32-1
rpm-4.11.1-1 <- may be bug here, as mock itself don't updated last time
yum-3.4.3-99.

How reproducible:
Always

Steps to Reproduce:
1. prepare directories for mock (in this example - /home/var/lib/ and /home/atu/mock)
2. mock --init --resultdir=/home/atu/mock/
3. ll /home/var/lib/mock/bcx-rawhide-i386/root/var/lib/rpm
total 16952
-rw------- 1 root root   782336 Jul  1 23:09 Basenames
-rw------- 1 root root     8192 Jul  1 23:09 Conflictname
-rw------- 1 root root   176128 Jul  1 23:09 Dirnames
....
4. or mock  rebuild any package

Actual results:
wrong permissions on rpm db files, build failed.

Expected results:
good (644) permissions, build with success (if package is good).


Additional info:
rpm itself makes db files with correct permissions:

# rm /home/var/lib/mock/bcx-rawhide-i386/root/var/lib/rpm/*
# rpm --root /home/var/lib/mock/bcx-rawhide-i386/root/ --initdb
# ll /home/var/lib/mock/bcx-rawhide-i386/root/var/lib/rpm
 total 104
-rw-r--r-- 1 root root  8192 Jul  1 23:30 Basenames
-rw-r--r-- 1 root root  8192 Jul  1 23:30 Conflictname
-rw-r--r-- 1 root root  8192 Jul  1 23:30 Dirnames
Comment 1 Anton Guda 2013-07-11 18:32:29 UTC 
Created attachment 772378 [details]
Dirty hack - but a working workaround

Sorry, python is not one of my native languages.
It may be worth to mention replacement of dirs to symlinks
/var/lock, /var/run
Comment 2 Fedora End Of Life 2013-09-16 14:20:53 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 3 Chris Leech 2013-09-19 17:02:13 UTC 
I just hit this after a 18 -> 19 upgrade, but a clean install of 19 in a VM with the same package versions works fine.

after a successful mock --init

$ repoquery --installroot=/var/lib/mock/fedora-19-x86_64/root -a --installed
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/mock/fedora-19-x86_64/root/var/lib/rpm
Traceback (most recent call last):
  File "/usr/bin/repoquery", line 1543, in <module>
    main(sys.argv)
  File "/usr/bin/repoquery", line 1413, in main
    repoq.conf
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1054, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 344, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1036, in readStartupConfig
    startupconf.distroverpkg)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1187, in _getsysver
    raise Errors.YumBaseError("Error: " + str(e))
yum.Errors.YumBaseError: Error: rpmdb open failed
Comment 4 Chris Leech 2013-09-19 20:35:58 UTC 
I managed to compare an strace of an OK mock init with one from a system that's having these permission errors.  I found an odd umask(077) call that seems to be the problem, immediately after loading the lvm python module.

Turns out that this only happens if lvm2-python-libs is installed, which is setting umask for some reason.
Comment 5 Nils Philippsen 2013-09-20 08:18:34 UTC 
Hmm, I don't have lvm2-python-libs installed, a mock init (as root, otherwise strace won't work) doesn't exhibit the umask(077) call you mentioned either. I've just kicked of a "fedpkg mockbuild" run to see whether I still have the issue or whether it some update solved it maybe.
Comment 6 Nils Philippsen 2013-09-20 13:05:05 UTC 
Hmm, it seems my issue stems from having a basedir != /var/lib/mock. Ignore me.
Comment 7 Anton Guda 2013-09-20 13:53:09 UTC 
As basedir is a config parameter, mock must run independently of parameter value (assume that dir exist on good filesystem with lot of space).
Comment 8 Clark Williams 2013-09-27 20:13:16 UTC 
Remember that mock has to run on F{18,19,20} as well as rawhide and EPEL6, so I'm hesitant to add Anton's patch, at least without a lot of testing across all potential hosting distros. I'm not sure what changing those directories to symlinks would do on say an EPEL6 system. 

I'd be curious to see what would happen if you did it all on /var/lib/mock. If it works there then something is going wrong with the umask when resultdir is pointing elsewhere.
Comment 9 Anton Guda 2013-10-26 13:44:19 UTC 
Tested with standard place: /var/lib/mock.
The same result.
Comment 10 Anton Guda 2014-02-07 22:03:51 UTC 
Tested: mock-1.1.36-1
Works for me.
Thanks.