[Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)
notifications at github.com
Sat Jun 10 15:45:03 UTC 2017
The term "corruption" is highly unspecific: please avoid, and/or supply more specific details.
Yes, somewhat counter intuitively, the "read-only" operation of rpm -qa is writing to disk: at a minimum, shared read locks (and rpm-4.x.y also is trying to create an advisory file lock).
The mmap'ing to backing file store is necessary for the dbenv (which has locks and caches) to be shared between processes.
RPM itself has 2 "risky" implementations using BDB:
- fsync is disabled (for performance) by stubbing out a BDB vector.
- non-root access to databases (the more common DB term is "tables") without a dbenv (hence no shared locks).
Without fsync, there is no (strong) guarantee that multiple processes see the same data on the file system. In practice (on linux) this has not caused major problems: but that is NOT a claim that no problems exist.
Reading without taking out a shared read lock can segfault if/when a writer is updating an rpmdb. In practice, the exclusive file lock and the pattern of usage of RPM is such that an occasional segfault is tolerable. But its quite easy to demonstrate the problem by running many concurrent RPM queries and installs.
In practice, RPM creates an exclusive file lock that serializes writers (but readers mostly do not participate in the advisory locking scheme, at least last I checked).
If you are truly interested in stable/robust concurrent access to an rpmdb, then you MUST correct the above problems. Denying the creation of shared read locks, either through file system permissions (i.e. non-root) or sandboxing simply isn't going to provide stable/robust concurrent access to an rpmdb.
The better approach is to permit write access to the dbenv files (in the __db.00N files) either through file system permissions (like group writable 0664, and possibly a setgid bit and ownership on the rpm executable), or by configuring your sandbox to permit writes to the dbenv files.
Treating the dbenv files as transient cache and moving them into a separate directory may help with sandbox rule generation as well.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint