pld rpm 5.4.17

[Jeffrey Johnson]

> On Feb 24, 2017, at 5:03 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> 
>>> 
>> 
>> Update: still the same with uid>0 (no write permission to /var/lib/rpm).
>> It seems that DB_READ_COMMITTED and DB_READ_UNCOMMITTED require +w,
>> so they should be filtered out in unprivileged mode.
> 
> Issue explained:
> 
> DB_READ_COMMITTED and DB_READ_UNCOMMITTED are cursor/get/set/txn options.
> DB_RDONLY and DB_READ_UNCOMMITTED are open options.
> 
> But... DB_READ_COMMITTED and DB_RDONLY have the same value!
> So "read_committed" cannot be applied to dbi_oflags (should be in
> eflags?) and applied to DB->cursor operations, like it's done since rpm
> 5.4.17 (leaving DB_READ_COMMITTED bit from oflags to cursor causes DB_RDONLY
> bit to be passed as DB_READ_COMITTED, which conflicts with read-only database).
> 

I’m sure your analysis is correct …

… meanwhile what was the core issue? What problem are you trying to solve?

Issues relating to whether a cursor COULD (or SHOULD) read uncommitted data
are quite complex, including whether the flags are inherited from the database open
and applied to the cursor open. RPM code doesn’t directly set either of those flags,
and likely Just Works with either setting depending if/when correctly configured.

But there are almost no checks on the configuration from macros, and DB_CONFIG,
not RPM macros, is the preferred means of configuring Berkeley DB because standard
and documented.

FWIW, patches to RPM to open the database RDONLY, and then reopen RDWRITE,
are known to be racy. Attempts to “harden” an rpmdb trigger have never been shown to be
effective (in my experience), and triggers Yet Another Level Of Exclusive Locking just in
case in an attempt to avoid raciness.

Simplest would be to open RDONLY when querying/verifying and RDWRITE
when installing/erasing, and moving the file based dbenv into /var/cache/rpm
with 666 permissions or 660+setgid (or equivalent). But there’s no ability
to discuss these changes rationally, so everything never changes.

Opening a database RDONLY does not mean that there are no writes: in fact,
shared/read locks MUST be written even if the database is opened RDONLY.

What was the core issue? What problem are you trying to solve?

hth

73 de Jeff