Fix for rpmdb with SQLite3 backend

[radosroka]

When the daemon is reloading the trustdb, and the rpmdb file is concurrently processed as an object, the file descriptor is closed at the end of evaluation. A close() on the SQLite database file causes the locks to be dropped. As a result, subsequent RPM installations can corrupt the RPM database when fapolicyd is running.

[stevegrubb]

In init_fd_buffer, why use calloc if you are going to use memset to initialize with? (calloc would be unnecessarily initializing everything to 0.) Also, why use rlimits? It allows you to have a lot of files open. Wouldn't 16 suffice?

[radosroka]

In init_fd_buffer, why use calloc if you are going to use memset to initialize with? (calloc would be unnecessarily initializing everything to 0.) Also, why use rlimits? It allows you to have a lot of files open. Wouldn't 16 suffice?

I forget to change calloc back to malloc. I wanted to calculate size of the buffer from the maximum file descriptors available because more is better. During the testing I've seen that "rpm -i" can generate 5-6 fds.

This is recipe how to get rid of lock. When these rpms are not installed before it can definitely corrupt the database for the daemon. It causes either reading of incorrect data or SIGBUS or any other error from rpmdb.

# yumdowndloader tcsh
# rpm -i tcsh* # this will install normally
# rpm -i tcsh* ; rpm -i tcsh* ; # this needs to safe these 5-6 fds
# rpm -i tcsh* ; rpm -i tcsh* ; rpm -i tcsh* ;  # this needs to safe these 10-12 fds
...

[stevegrubb]

One last thing, I apologize for not catching this yesterday, when initializing the fd_buffer with memset shouldn't that be a "for" loop setting each integer to -1? memset works at the char level. It is more correct to set an integer array entry to an integer value.

[stevegrubb]

Also, in fapolicyd.c around line 574, we set the rlimit to 16K. Meaning that the fd_buffer size will be 4K. That's why I was asking if we can just declare it to be 16 and not derive it from rlimits?

[radosroka]

Also, in fapolicyd.c around line 574, we set the rlimit to 16K. Meaning that the fd_buffer size will be 4K. That's why I was asking if we can just declare it to be 16 and not derive it from rlimits?

I noticed that in valgrind, setting rlimit doesn't work. I believe this can be also the case for some machines with very low resources. In such case limit can drop to 1024, therefore manual setting for 512 because 256 would be too low. If fd buffer set to 16k and limit is 1024 it isn't hard to force the daemon to run out from fds.