[refpolicy] staff_t runs cronjobs as cronjob_t instead of staff_t in Fedora 11

[refpolicy] staff_t runs cronjobs as cronjob_t instead of staff_t in Fedora 11

[Dominick Grift]

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?

[refpolicy] staff_t runs cronjobs as cronjob_t instead of staff_t in Fedora 11

[Christopher J. PeBenito]

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.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] staff_t runs cronjobs as cronjob_t instead of staff_t in Fedora 11

[Dominick Grift]

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] staff_t runs cronjobs as cronjob_t instead of staff_t in Fedora 11

[Daniel J Walsh]

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.