Bug 92031

Description of problem:

Recently, I was trying to use rpm to find an installed package.  The command
was never returning...  rpm cannot be ctrl-c'ed so I did a ps to get the
pid.  What I found through the ps was a large number of processes running
that should not have been.

Basically what appears to have happened is:

- a query to the rpm database somehow locked the database and never cleaned
  up the lock
- cron kicked off updates to the rpm /var/log/rpmpkgs file and the
  slocate database

Since these processes are kicked off by cron via /etc/cron.daily there were
about 15-20 of them running, as well as their child processes.  It is unknown
whether the original application that queried the rpm database has exited,
crashed, etc.  After killing all the processes I could find that I knew dealt
with the rpm database, I still cannot do a query.  A reboot will need to be
performed.

This could eventually generate a denial of service attack against the system.
If a malicious user knows the default time that rpm/slocate do their updates,
locking the rpm database and causing them to hang will stack up the number
of processes running.  The system could then run out of unique process IDs
and swap/memory space.

Possible workarounds could be to remove the ability for any but trusted
users to run rpm commands.  If one of these user accounts is compromised,
the problem will still exist.

Version-Release number of selected component (if applicable):

This was discovered on a RedHat 8.0 systembut will probably exist on RedHat 9
as well as older releases.  Most likely this will affect any system that uses
rpm to manage packages and has cron scripts to do periodic updates.

I cannot give specific versions of rpm/slocate/cron/etc. at this time.  I
need to perform a reboot in the hopes of fixing the rpm deadlock.


How reproducible:

Unknown.  There is a bit of timing involved.  If you can craft a simple
application to query the rpm database and exit without releasing the lock
it should be easy.  Then it is just a matter of time until 

Steps to Reproduce:

These are approximate steps for reproducing the problem...

1. Cause the rpm database to remain in a locked state
2. Run the daily rpm and slocate cron jobs several times and observe them
   stacking up in the process queue


Actual results:

System tends to slow down as memory and virtual memory are filled.  Subsequent
queries against rpm database from command line do not work.  up2date will
not run as it cannot get a lock on the database.  This could present a problem
if a critical patch needs to be installed.  This in turn will lead to possible
root exploits being left open.  (cascading effect)


Expected results:

This should never occur.


Additional info:

Until solved, it may be necessary to disable the daily rpm and slocate
scripts from running.