I can confirm this. I've installed both openenoffice 1.1.4 and 2.0-beta in /opt.
Both version won't start anymore, while causing "avc denied" messages. 
In addition the flash plugin installed in my home directory
(~/.mozilla/plugins/) won't start while causing "avc denied" messages.

I've already extecuted "fixfiles relabel" and I've rebooted.

The severity of this bug is very high!

I can't even load shared libraries from subfolders of my home directory !!

I hope there's a fix soon !!

What errors are you seeing?  What are the AVC messages?

Dan

I wiped out some sensible data:

This message is the result when trying to load a shared library in my home
directory. LD_LIBRARY_PATH is set correctly and it worked before the latest
selinux-policy-targeted update.

Jun 13 11:17:03 mymachine kernel: audit(1118654223.196:0): avc:  denied  {
execmod } for  pid=6155 comm=testprog path=/home/user/workspace/prog/libprog.so
dev=hda5 ino=1458690 scontext=user_u:system_r:unconfined_t
tcontext=user_u:object_r:user_home_t tclass=file


This message appears thousands of times, caused by mozilla's flashplayer:

Jun 13 11:13:59 mymachine kernel: audit(1118654039.474:0): avc:  denied  {
execmod } for  pid=4663 comm=firefox-bin
path=/home/user/.mozilla/plugins/libflashplayer.so dev=hda5 ino=1409670
scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:user_home_t
tclass=file


This message appears, when trying to start openoffice. I've installed the
openoffice version from openoffice.org.

Jun 13 11:21:52 mymachine kernel: audit(1118654512.067:0): avc:  denied  {
execmod } for  pid=6188 comm=soffice.bin
path=/opt/openoffice.org1.9.104/program/libicudata.so.26.0.1 dev=hda6 ino=54865
scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:usr_t tclass=file

the same happens with the current stable openoffice version:

Jun 13 11:22:53 mymachine kernel: audit(1118654573.135:0): avc:  denied  {
execmod } for  pid=6215 comm=soffice.bin
path=/opt/OpenOffice.org/program/libicudata.so.22.0 dev=hda6 ino=51385
scontext=user_u:system_r:unconfined_t tcontext=root:object_r:usr_t tclass=file

The system itself is stable, but these few examples show, that there's something
wrong !!

If I knew how to configure this big selinux monster, I'd try to find the bug
myself. Do you have any comprehensible tutorials?

http://fedora.redhat.com/docs/selinux-faq-fc3/

In short: 
  - directory /etc/selinux/targeted/src/policy
  - do 'make install' after policy change
  - do 'fixlabels restore' to set context in whole filesystem,
    or read 'man setfiles' if you want change just one dir/file or test

I guess the bug is somewhere in selinux binary. Try remove all '--' and all
should work again. I see in previous release '--' was used too, but not so much,
so no error was visible (lib_t is enough for libraries, but desired idea was to
use shlib_t in /usr/lib, for example).

(should work again except the /opt/.*lib dir, of course)

"I guess the bug is somewhere in selinux binary. Try remove all '--' and all
should work again. I see in previous release '--' was used too, but not so much,
so no error was visible (lib_t is enough for libraries, but desired idea was to
use shlib_t in /usr/lib, for example)."

Sorry, but I didn't understand you.
What do you mean by "removing all '--' " ?? Could you please explain it again?

I mean remove all '--' from configuration file /etc/selinux/targeted/src/policy/
file_contexts/types.fc.

So commands like this:
  cd /etc/selinux/targeted/src/policy/
  # correct '--'
  cp file_contexts/types.fc file_contexts/types.fc.orig
  cat file_contexts/types.fc.orig | sed -e 's/--//' > file_contexts/types.fc
  # corect there /opt/lib too, according to my previous mail
  (vi file_contexts/types.fc)
  make install
  fixlabels restore

PS: I'm just bug reporter. I wasn't so active to explore selinux sources...

I've followed your hint, but it didn't help, sorry.

Am I the only one who has this problem? I am wondering, why there are so few bug
reports about this issue.

Where could be the reason?

I've got the same selinux-policy as other users, and I've done "filfiles
relabel" dozens of times the last days...

Hmm, I checked the 1.17.30-3.9 version in testing updates of FC3 and the
opt-problem wasn't fixed yet. :-(

Good message: '--' was fixed. :-)

I think developers was notified about this bug, so if previous selinux policy
was OK for you, I advice you downgrade back to version 1.17.30-2.96 for now
(remove and install old, maybe '--force' would work too...) and relabel again.

If you install 1.17.30-3.9 and 

setsebool -P allow_execmod=1

Does this fix the problem?

I have no idea why downgrading to previous policy would fix this problem.  This
problem comes because of the new kernel.  Basically the kernel update contains
new AVC checks execmod/execmem, and policy did not handle it in the past.

Dan

Fixed in selinux-policy-targeted-1.17.30-3.9

Yes, you're right. It's fixed. 

Now there remains only minor bug (it hasn't effect to functionality):

[valtri@funus ~]$ ls -lZ /opt/lib/*.so | head -1
lrwxrwxrwx  root     root     system_u:object_r:usr_t         
/opt/lib/libavcodec.so

I think desired is:

lrwxrwxrwx  root     root     system_u:object_r:shlib_t         
/opt/lib/libavcodec.so


Anyway it works nice on my system, now. Thank you.

Does restorecon -R -v /opt fix the labeling?

No, it doesn't.

[root@funus valtri]# restorecon -R -v /opt
[root@funus valtri]# ls -Z /opt/lib/*.so | tail -1
lrwxrwxrwx  root     root     system_u:object_r:usr_t          /opt/lib/libxine.so

What version of policy do you have installed?

1.17.30-3.9 - the latest from FC3 updates.

Btw. look at /etc/selinux/targeted/src/policy/file_contexts/types.fc. There is:

/opt/.*/lib(64)?(/.*)?

shouldn't it be:

/opt/lib(64)?(/.*)?

?

Not quite but it is broken.

/opt(/.*)?/lib(64)?(/.*)?

Is in the next test release.

selinux-policy-targeted-1.17.30-3.15

Installed selinux-policy-targeted-1.17.30-3.13 from FC3 and all is OK now.

Thank you.