Bug 159285 - rpm doesn't lock db in chroot
Summary: rpm doesn't lock db in chroot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-01 12:55 UTC by Rafael Garcia-Suarez
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-18 20:18:38 UTC
Type: ---
Embargoed:


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

Description Rafael Garcia-Suarez 2005-06-01 12:55:24 UTC
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:
Always

Steps to Reproduce:



Additional info:

Comment 1 Rafael Garcia-Suarez 2005-06-01 12:57:35 UTC
Created attachment 115025 [details]
Patch against rpm 4.4.1

Comment 2 Jeff Johnson 2005-07-01 10:13:39 UTC
The transaction lock is/was intended to be per-system, not per-chroot, nor per-rpmdb.

Comment 3 Rafael Garcia-Suarez 2005-07-01 10:33:59 UTC
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 11:10:18 UTC
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 20:18:38 UTC
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.