From: dwalsh@redhat.com (Daniel J Walsh)
Date: Wed, 27 May 2009 11:34:19 -0400
Subject: [refpolicy] staff_t runs cronjobs as cronjob_t instead of
 staff_t in Fedora 11
In-Reply-To: <1243430430.3633.9.camel@notebook2.grift.internal>
References: <1242936317.3383.4.camel@notebook2.grift.internal>	<1243429020.5421.1.camel@gorn>
	<1243430430.3633.9.camel@notebook2.grift.internal>
Message-ID: <4A1D5D7B.1060307@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 05/27/2009 09:20 AM, Dominick Grift wrote:
> On Wed, 2009-05-27 at 08:56 -0400, Christopher J. PeBenito wrote:
>> On Thu, 2009-05-21 at 22:05 +0200, Dominick Grift wrote:
>>> I am not sure if this issue can be reproduced on non Redhat distros but
>>> here in Fedora 11 cronjobs by staff_t get executed in the cronjob_t
>>> domain.
>>>
>>> This is not very handy because if staff_t wants to back up his home
>>> directory for example, then cronjob_t cannot access it.
>>>
>>> I am wondering why it runs as cronjob_t?
>> Running in cronjob_t is expected.  However it has permissions to manage
>> user home dir content, so I'd only expect denials if the seuser didn't
>> match.
>>
>
> I guess this is a RedHat specific issue. I have reported the "bug" to
> bugzilla.redhat.com.
>
> Not sure if Fedora patched out the part where it has access to user home
> content but here on Fedora 11 cronjob_t cannot access it and UBAC isnt
> enabled.
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
It has never made any sense to me to run cronjobs in a context other 
then the users context.  It just creates bugs and potentially mislabeled 
files.  For example a user runs a cronjob that creates content in the 
users directory.  If he runs it as him self the file gets labeled 
correctly. If he runs it in Cron it does not.  The user has the 
expectation that this is a bug and he is correct.