Bug 193488
| Summary: | Incorrect SELinux context of /usr/lib/gconv/gconv-modules.cache | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Robert Scheck <redhat-bugzilla> |
| Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
| Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dwalsh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 4.4.2-25 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-06-30 09:02:50 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
Robert Scheck
2006-05-29 17:48:27 UTC
At least on FC5 I have installed glibc-post-upgrade.{x86_64,i686} creates
the cache with user_u:object_r:lib_t and that's what restoreconf keeps it at.
The problem here is that rpm should be ignoring the SELinux user componant of the security context. Ignoring? Describe the conditions necessary for deterministic behavior in rpm please. In SELinux terms the files SELinux user is the user who created it "user_u", or the system default "system_u". So when you relabel the system the context gets reset to system_u, which matches exacly what is in the file_contexts file. When the file gets created via a user (root) it gets labeled user_u, (Or root, sysadm_u, staff_u ...) Depending on which SELinux user created. So since RPM can not tell the difference, the user componant of the SELinux context should be ignorred for this check. Hmmm, that reads like
Please ignore the wizard behind the screen.
hand waving to me, YMMV, certainly seems to. I have not the foggiest idea
under what conditions the user component should be ignored, and we seem
to agree "RPM can not tell the difference."
There are two non-wonderland fixes that I can see:
1) Create the file from packaging with "system_u" so relabel changes nothing.
That implementation should happen in policy, seems like it is already there.
2) Change the lazy creation of the file so that the file is "system_u", not "user_u", when created.
Neither 1) or 2) is a rpm problem.
Hey folks, why can't we simply get SELinux out of RPM? Dlopen() it or whatever fits and it will get a libselinux bug like #193489 which really has to be fixed within libselinux and not by hacking ugly things in RPM... ;-) I agree remove the rpm -V functionality for SELInux and use restorecon and friends to verify the file context. *** Bug 193489 has been marked as a duplicate of this bug. *** As far as I can see, verify of SELinux contexts has been removed in Rawhide by rpm-4.4.2-noselinux-verify.patch used in rpm-4.4.2-25, thanks. |