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...
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.
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!
Whoops! I meant "Marked as Fixed" (not fixed).
this is still a bug in FC5 final
What are you reporting is still a bug? libflash being stalled with the wrong
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/