Bug 159285 - rpm doesn't lock db in chroot
rpm doesn't lock db in chroot
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-06-01 08:55 EDT by Rafael Garcia-Suarez
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-18 15:18:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch against rpm 4.4.1 (634 bytes, patch)
2005-06-01 08:57 EDT, Rafael Garcia-Suarez
no flags Details | Diff

  None (edit)
Description Rafael Garcia-Suarez 2005-06-01 08:55:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322

Description of problem:
The following command tries to lock the rpmdb in /var/lib/rpm (i.e. %_dbpath) instead of /tmp/root/var/lib/rpm :

$ rpm --root /tmp/root --rebuilddb
error: can't create transaction lock on /var/lib/rpm/__db.000

I think that the root should be prepended to %_dbpath and to macros that depend on it (in this case %_rpmlock_path).

As a quick hack I'll join a patch that fixes this immediate problem.

Version-Release number of selected component (if applicable):
rpm 4.4.1

How reproducible:

Steps to Reproduce:

Additional info:
Comment 1 Rafael Garcia-Suarez 2005-06-01 08:57:35 EDT
Created attachment 115025 [details]
Patch against rpm 4.4.1
Comment 2 Jeff Johnson 2005-07-01 06:13:39 EDT
The transaction lock is/was intended to be per-system, not per-chroot, nor per-rpmdb.
Comment 3 Rafael Garcia-Suarez 2005-07-01 06:33:59 EDT
So, what you suggest is to lock all bases of the system ? (Rationale -- If you
only lock the 'main' rpmdb when doing a --rebuilddb in a chroot, this is unsafe,
because the rpmdb in the chroot can still be accessed by a user running rpm in
this chrooted environment.)
Comment 4 Jeff Johnson 2005-07-01 07:10:18 EDT
The fcntl transaction lock serializes installs/upgrades, not the database. There will always
be "unsafe" operations wrto installs no matter what path is chosen for the fcntl lock path.
E.g. the fcntl lock is advisory, not mandatory, and there are legacy versions of rpm commonly installed
in chroot's that will not conform.

The concurrency locks are known to protect rpmdb data quite well with concurrent writes.

"Don't do --rebuilddb while installing." as a policy mandate seems a perfectly adequate and obvious 
solution to me, i.e. no locks at all. In fact, --rebuilddb is hardly ever necessary any more.
Comment 5 Jeff Johnson 2005-11-18 15:18:38 EST
The fcntl transaction lock is now defaulted off in macro configuration (rather than on) in rpm-4.4.4-0.2 
and later.

The rationale for doing so is that there is no one, or even multiple, paths that can be locked to prevent
multiple upgrades, given older versions of rpm in chroot's etc etc. I see no reason to pretend that
an fcntl lock is adequate to serialize transaction installs.

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