<p>The term "corruption" is highly unspecific: please avoid, and/or supply more specific details.</p>
<p>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).</p>
<p>The mmap'ing to backing file store is necessary for the dbenv (which has locks and caches) to be shared between processes.</p>
<p>RPM itself has 2 "risky" implementations using BDB:</p>
<ul>
<li>fsync is disabled (for performance) by stubbing out a BDB vector.</li>
<li>non-root access to databases (the more common DB term is "tables") without a dbenv (hence no shared locks).</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>Treating the dbenv files as transient cache and moving them into a separate directory may help with sandbox rule generation as well.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307572921">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb800UqyNbsMiMLAyihwCEw9hrI8bDOks5sCrn_gaJpZM4NzFoB">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb80ydzZi-YVisKR7OPSbinOnGdj6y5ks5sCrn_gaJpZM4NzFoB.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307572921"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #232: The term \"corruption\" is highly unspecific: please avoid, and/or supply more specific details.\r\n\r\nYes, 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).\r\n\r\nThe mmap'ing to backing file store is necessary for the dbenv (which has locks and caches) to be shared between processes.\r\n\r\nRPM itself has 2 \"risky\" implementations using BDB:\r\n- fsync is disabled (for performance) by stubbing out a BDB vector.\r\n- non-root access to databases (the more common DB term is \"tables\") without a dbenv (hence no shared locks).\r\n\r\nWithout 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.\r\n\r\nReading 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.\r\n\r\nIn 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).\r\n\r\nIf 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.\r\n\r\nThe 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.\r\n\r\nTreating the dbenv files as transient cache and moving them into a separate directory may help with sandbox rule generation as well."}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/232#issuecomment-307572921"}}}</script>