Red Hat Bugzilla – Bug 425985
f-prot downloaded files have type rpm_script_tmp_t
Last modified: 2007-12-18 10:00:47 EST
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
New virus definitions are given the selinux context of:
This then creates selinux avc errors later when I run virus scans.
Note that these new definitions are saved (by default) in:
All the other f-prot rpm files in the directory have the (benign) selinux
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
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