Description of problem: Many advances have been added to matchpathcon that rpm does not support. Admins can do local customization of file_context and homdircontext are picked up by latest matchpathcon.
*** Bug 152611 has been marked as a duplicate of this bug. ***
Since 152611 has been marked as a duplicate, I'll give a brief synopsis of the other bug (which was marked as an FC4 Blocker) because this is not so much an RFE as it is a serious problem. With a clean install of FC4, the /home (and sub) directories are being set up with the wrong security context: #ls -ldZ /home drwxr-xr-x root root system_u:object_r:default_t /home After I restorecon it: drwxr-xr-x root root system_u:object_r:home_root_t /home The manifestation of this problem in the previous bug was that Flash would not install properly in Firefox, as the installed files in the home directory had the wrong context (to try it out, just head to a flash-enabled site and load firefox through the presented option). Flash will not work until you restorecon your ~/.mozilla directory. A clean install of FC4 should ship with the correct security context on the home directory, as SELINUX is shipping enabled by default (IIRC). Just my 2 cents... -Sean :)
Yes basically in FC4 file context has been broken into two or more files. By default there is file_context and file_context.homedirs. The /root and /home are defined in the homedirs file. Since RPM does not use matchpathcon it is only reading file_context and defaulting those files to default_t. Which causes problems later when people add accounts. Unconfined_t is not allowed to exec and execmod sharedlibraries on homedirectories.
*** Bug 156895 has been marked as a duplicate of this bug. ***
rpm-4.4.1-18.1 should use matchpathcon everywhere. Testing appreciated.
Currently running it on a machine with strict policy. Question: Is there a testsuite that covers certain aspects of rpm that are likely to be problematic, e.g. chroot environments, emul prefixing, etc? How are they being handled now when using matchpathcon, since matchpathcon knows nothing about them currently? Does matchpatchcon need to incorporate a notion of a variable root directory, or can we just assume that the caller will strip the root prefix prior to invoking it?
I just did a clean install of FC4T3, and was able to install flash via Firefox with no problems at all (this was broken with the older version of RPM). This bug can be fixed as far as I am concerned. Thanks! -Sean
Whoops! I meant "Marked as Fixed" (not fixed). Thanks, -Sean
this is still a bug in FC5 final
What are you reporting is still a bug? libflash being stalled with the wrong security context?
Bruce - please give more details, codewise rpm is using matchpathcon. What exactly is the issue?
Re: comment #12, flash is still NOT recognised even though it is installed. Daniel I imagine that it is the wrong security context since disabling selinux fixes the problem (please see the bug https://bugzilla.mozilla.org/show_bug.cgi?id=331753 i reported ). This bug may be of interest also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152611
So this is not a rpm problem, but a file context problem. The problem is there shared library is being installed in the users home dir and needs to be labeled textrel_shlib_t or else it will blow up with a execmod error. I have added a tool to fc5 call restorecond that might solve this problem. Is this library always going to be in .mozilla/plugins/ Dan