Bug 425985
Summary: | f-prot downloaded files have type rpm_script_tmp_t | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Need Real Name <bugzilla> |
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 8 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-12-17 21:50:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2007-12-17 16:25:18 UTC
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. |