RPM Query behavior via sudo vs user

[gclair]

There seems to be a behavior difference when executing rpm -qa or rpm -qa --qf %{NAME} via sudo vs a non-privileged user. When executing via sudo its been shown to error out with a bad DB:

hirpmdb: Thread/process 85454/140624466790144 failed: Thread died in Berkeley DB library
error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 -  (-30974)
error: cannot open Packages database in /var/lib/rpm

The issue is clear and the fix is known, however the same host (RedHat) without sudo, seems to work even with the db issue.

% sh -c 'printf hi; /bin/rpm -qa --qf %{NAME}\\n'
hikernel-headers
at
pkgconfig
nss-sysinit

The question is why is the behaviour different between the command executing as root vs a regular user?

I tried to search the code base but my knowledge is limited, and I'm guessing it has something to do with perhaps establishing a file or db lock or attempting to write to the db as root for some reason vs a pure read only as a user.

Any ideas?

[pmatilai]

The regular user doesn't have write-permissions on the shared database environment (those __db.* files), which is required to register even a read-lock in there. So when running as a regular user, rpm cheats by using a private environment, which amounts to no locking at all wrt a concurrent writer. As in, it's unreliable and broken but the alternative of not allowing any queries for regular user is not really an option either.

Note that this is specific to the deprecated Berkeley DB backend which has been entirely dropped upstream. The newer backends do not have such an issue.

[gclair]

Thank you! Very helpful!