Description of problem: I am using f-prot to do virus scanning on my machine. I installed the rpm: fp-linux-ws-4.6.8-1.i386.rpm Everything works fine EXCEPT that when I update the virus definitions using the script: /usr/local/f-prot/tools/check-updates.pl New virus definitions are given the selinux context of: system_u:object_r:rpm_script_tmp_t This then creates selinux avc errors later when I run virus scans. Note that these new definitions are saved (by default) in: /usr/local/f-prot/MACRO.DEF /usr/local/f-prot/SIGN.DEF /usr/local/f-prot/SIGN2.DEF All the other f-prot rpm files in the directory have the (benign) selinux context of: system_u:object_r:usr_t What needs to be done so that these definition files get created with a more standard selinux type rather than rpm_script_tmp_t?
THe problem here is these files are getting created in /tmp and then mv'd to /usr/local. They need to have restorecon -R -v /usr/local/f-prot run on them after the move. You should report a bug to f-prot to fix this to work with SELinux.
OK - I'm not sure I understand. I thought that files created in /tmp have something like system_u:object_r:unconfined_temp_t as their default selinux types. I don't understand how/why these temp files are created with type rpm_script_tmp_t. Also, just to clarify, are you saying that there is no policy solution but rather after each virus definition update, one needs to run "restorecon" This would seem to be a bit of a kluge since it would presumably break the rpm on systems that don't have selinux installed.
These temp files are created with rpm. when unconfined_t runs rpm it transitions to rpm_t which transitions to rpm_script_t when running scripts. rpm_script_t will create files in tmp as rpm_script_tmp_t. If these files were cp'd the correct context would get applied. IE the context of the destination directory, usr_t. If the files are mv'd they will retain the context that they were created with, rpm_script_tmp_t. If the files were installed directly from rpm, they would get the correct context. So the postinstall either needs to use cp instead of mv, and then delete the files, or it can run restorecon on the files after it has moved them. There is no way in policy to guess what the intention of the mv and cp commands. This is similar to DAC permissions. In that if RPM created the /tmp files with 700 permissions and then wanted them world readable when it moved them to /usr, it would have to execute chmod on the files.
Dan thanks for the detailed explanation but I was not talking about initial installation. The problem that I reported is that EVERY time the perl script "check-updates.pl" is run, it creates files with context rpm_script_tmp_t. However, I did find the problem. The /var/tmp/f-prot directory ITSELF has context unconfined_u:object_r:rpm_script_tmp_t which is obviously the root cause and easily changeable. So problem SOLVED and thanks for the help in steering me to look at the tmp file directory.