Try to execute

#setsebool cron_userdomain_transition on

I tested that and that seemed to fix things. The puzzling thing is when I tried turning it back off, things kept working. (Though I didn't reboot or restart cronie when I did that.) I had recently upgraded the machine from f20 to rawhide and had an issue where some posttrans scripts might not have been run. It looks like cron_userdomain_transition is new to rawhide so if a default of on was set in a posttran script, that could explain why I ran into the problem.

I checked changing cron_userdomain_transition and restarting crond after each change and when I did that I did need to have it on for things to work.

Dominick,
what was the purpose of this change? I mean this boolean.

The user_cron_spool_t is an important part of this functionality by changing the label of the "domain entry file" to usr_t you break the functionality.

Basically crond uses the crontab's as an entry point to a the target domain specified by policy.

So were just saying:

if cron_userdomain_transition is off then:

cronjob_t user_cron_spool_t:file entrypoint;

and if it is on then:

myuser_t user_cron_spool_t:file entrypoint;

Crond computes in which domain to run the cronjob by looking up which transitions are available.

user_cron_spool_t is the entrypoint to the specified target domain and so it is an important port of the functionality.

So the bug is in the fact that OP changed the type of the crontab from user_cron_spool_t to usr_t. We need to figure out why he wanted/needed to do that, because it should really stay user_cron_spool_t.

By the way if its not done already: you might want to default to cron_userdomain_transition to on by default in Targeted policy, and to off by default in MLS policy. (at least that is probably what i would do, its a matter of taste i guess though)

Yes because I have a problem with

Feb 10 14:48:54 cerberus crond[3055]: (bruno) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/bruno)

How do we go to tell a user turn on the boolean?

We should not have to tell a user to set the boolean. I do not see what that message implies.

It should be as simple as :

if the cron_userdomain_transition is set to on then run the job in the calling user domain, else run it in cronjob_t.

So i am not sure why its complaining about unauthorized SELinux context. Where does it it get that context from? (maybe default_contexts?)

I guess i could try and install rawhide to see if i can reproduce. I haven't heard of similar issues with other distros using this solution.

Yes it comes from default user contexts. For example

system_r:crond_t:s0		unconfined_r:unconfined_t:s0

so if there is a cronjob then crond_t looks here for this info and sets "unconfined_t". But of course crond_t does SELinux checks and this is a reason why we get it.

Which of course does not work with this rawhide feature.

I think i figured out the issues

First issue is that the default contexts differ with refpolicy (both for users and default_contexts)

The second is that in Fedora file_unconfined_type cannot "entrypoint" of all file_type (why?) where as in refpolicy it can.

So in fedora we need some modifications

We need to explicitly allow unconfined_cronjob_t user_cron_spool_t:file entrypoint; if cron_userdomain_transition=1

and we need to edit the /etc/selinux/targeted/contexts/users/* to make it first try *.cronjob_t and then $USERDOMAiN

we also need to adjust /etc/selinux/targeted/default_contexts to include unconfined_r:unconfined_cronjob_t (and others)

Ill make a screencast of my manual test for reference purposes

here is a quick rundown of the issue and proof of concept:

https://www.youtube.com/watch?v=V3VXePNuUv8

Please try it out. if questions let me know

(might still be processing)

(In reply to Dominick Grift from comment #11)
> I think i figured out the issues
> 
> First issue is that the default contexts differ with refpolicy (both for
> users and default_contexts)
> 
> The second is that in Fedora file_unconfined_type cannot "entrypoint" of all
> file_type (why?) where as in refpolicy it can.

Yes, rawhide entrypoint changes.

> 
> So in fedora we need some modifications
> 
> We need to explicitly allow unconfined_cronjob_t user_cron_spool_t:file
> entrypoint; if cron_userdomain_transition=1
> 
> and we need to edit the /etc/selinux/targeted/contexts/users/* to make it
> first try *.cronjob_t and then $USERDOMAiN
> 
> we also need to adjust /etc/selinux/targeted/default_contexts to include
> unconfined_r:unconfined_cronjob_t (and others)

Well I will need to re-check all this new concept and play with it more to see if we can get it working in Fedora(also MLS).

> 
> Ill make a screencast of my manual test for reference purposes

A correction for comment 5. I only switched to usr_t on the machine where I noticed the problem, after the user_cron_spool_t label was causing a problem. usr_t actually seemed to work as a work around. I tried that label because another rawhide machine still had a cron file with a usr_t label, as I apparently hadn't done a full relabel since the change on that machine.

Ok going thru this bug and sure it can be fixed how Dominick wrote.

But basically I am not big fan of this concept. I believe we want to see user cronjobs running in a userdomain for all cases. I don't understand why we would make a difference. Also cronjob_t caused issues on MLS systems. It was a reason why we switched to have a userdomain.

I am going to turn on the boolean by default but keep this bug opened to discuss.