Bug 980244 - Wrong (r600) permissions on rpm db files - mock builds failed
Wrong (r600) permissions on rpm db files - mock builds failed
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Clark Williams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-01 16:33 EDT by Anton Guda
Modified: 2014-02-07 17:03 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-07 17:03:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Dirty hack - but a working workaround (3.30 KB, patch)
2013-07-11 14:32 EDT, Anton Guda
no flags Details | Diff

  None (edit)
Description Anton Guda 2013-07-01 16:33:59 EDT
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):
rpm-4.11.1-1 <- may be bug here, as mock itself don't updated last time

How reproducible:

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 14:32:29 EDT
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 10:20:53 EDT
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:
Comment 3 Chris Leech 2013-09-19 13:02:13 EDT
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>
  File "/usr/bin/repoquery", line 1413, in main
  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
  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 16:35:58 EDT
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 04:18:34 EDT
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 09:05:05 EDT
Hmm, it seems my issue stems from having a basedir != /var/lib/mock. Ignore me.
Comment 7 Anton Guda 2013-09-20 09:53:09 EDT
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 16:13:16 EDT
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 09:44:19 EDT
Tested with standard place: /var/lib/mock.
The same result.
Comment 10 Anton Guda 2014-02-07 17:03:51 EST
Tested: mock-1.1.36-1
Works for me.

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