This looks like you have a mislabeled homedir.

restorecon -R -v ~/

Do you have mozplugger installed?

If yes you probably need to turn off the confinement.

setsebool -P unconfined_mozilla_plugin_transition 0

*** Bug 741438 has been marked as a duplicate of this bug. ***

I don't have mozplugger installed, no.

fabian: why is liborc still creating these orcexec.* files in user home directories rather than /tmp?

This is a good question.

I guess we are going to have to support this.

<grift> fabiand any new on why liborc still puts orcexec.* file in user home dirs instead of /tmp?
<grift> those orcexec files should go to tmp
<fabiand> grift: that can be because tmpfs is noexec 
<fabiand> and afaik the logic tries /tmp but falls back to $home if it can not be executed there ..
<fabiand> it's more dramatic that they sometimes don't get removed ..

<grift> fabiand i see, makes sense
<fabiand> grift: there is an update out for 14/15 which fixes some problems, i'll push it to 16 when the beta is out ..

Maybe those are based on the same problem:
https://bugzilla.redhat.com/show_bug.cgi?id=723001
https://bugzilla.redhat.com/show_bug.cgi?id=741437

In a default setup /tmp is noexec, so orc is falling back to XDG_RUNIME_DIR and HOME. 
What place would be a viable solution for you selinux guys/grils?

This is a bug in liborc and were waiting for a fix in F16.

Any reports where name="orcexec.*" we can likely chalk up to this bug.

http://code.entropywave.com/git?p=orc.git;a=commit;h=fbc554f450e37380104e2730d8685caf37abe24c

Let me explain the issues involved here.

different apps use the liborc. Usually a default user will not notice this issue.
except when a confine domain uses liborc

for example gnash in the mozilla plugin domain. gnash calls liborc which makes gnash create a file in $home in the current case the file has a random suffix. so the file gets created with for example mozilla_home_t type. Restorecond -u picks it up as mislabelled and resets the context (usually to user_home_t) this causes that the confined domain can no longer write to it or delete it. So we end up with orcexec files in the home dir that arent deleted.

We cannot add a file context for this because different apps (domains) call liborc , for example totem-thumbnailer. So we cant tell selinux what the label should be. should it be mozilla_home_t or thumb_home_t or, or,?

the named file trans could maybe help here but the random suffix breaks it. We could for example say if a domain creates a file with name orcexec.1 then type transition to orc_home_t if another domain creates a file with orcexec.2 then type transition to orc_home_t as well. As long as its not a random suffix and it uses a reasonable range [0-10]?

Then we CAN add a file context spec HOME_DIR/orcexec.* -- gen_context(system_u:object_r:orc_home_t,s0)

We need to find a way to make this work regardless of whether orc fixes the /tmp and home ordering. Because if for some reason tmp or tmpfs cannot be used (noexec?) then it will try to fallback to home.

Issue where orc creates files in ~ by default rather than /tmp is fixed in orc-0.4.16-1.fc16.x86_64.rpm.

Could we change the default so it creates the file under .config or .local

AFAIK this can easily be patched and maybe upstream is also interested if there are valid arguments in using those locations.

(In reply to comment #11)
> Could we change the default so it creates the file under .config or .local

why do you want that? I do not see how that changes anything.

Confined user domains have rules about labels on files created in ~/ and more significance can be placed on these files in these directories.  If we create a directory in .config/orc/  And create the orc content there, we can allow all of the confined apps created orc_home_t.  And then we could use a named_file_trans rule to make sure .config/orc gets created with the correct context.

I see you point but you are not explaining it right i believe.

Let me try:

1. we cannot use a named file transition because of the random suffix of the orcexec.* files.

2. we can use the named file transition *if* orc creates a dir (~/.cache/orc) and then create these orcexec.* files in there.

because we *can* define a rule for the orc dir but not for the orcexec.* files:

# create orc dir in ~/.cache with a named file transition
manage_dirs_pattern($1, orc_cache_home_t, orc_cache_home_t)
filetrans_pattern($1, cache_home_t, orc_cache_home_t, dir, "orc")

# allow orc to manage/exec orcexec.* files in directories with type orc_cache_home_t
manage_files_pattern($1, orc_cache_home_t, orc_cache_home_t)
exec_files_pattern($1, orc_cache_home_t, orc_cache_home_t)

And then:

HOME_DIR/\.cache/orc(/.*)? gen_context(system_u:object_r:orc_cache_home_t,s0)

That is the idea.  

.cache is a better directory for this also.

i will pitch this idea at #orc

I've just build orc with a patch, putting all temporary files into a subdir, could you try it and give some feedback?
https://koji.fedoraproject.org/koji/taskinfo?taskID=3434537

So is this fixed in the current release?

*** Bug 741437 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> So is this fixed in the current release?

From my pov yes. I tried to grab Dominick Grift a cuople of times, so he could check if the selinux rules are in place and the whole think works (he requested the change in orc).