[refpolicy] unconfined_cronjob_t et al

[refpolicy] unconfined_cronjob_t et al

[Russell Coker]

Is anyone actually making use of domains such as unconfined_cronjob_t?

Is there any reason why I shouldn't just unilaterally remove them from the 
Debian policy for Squeeze regardless of what Red Hat and upstream are doing?

It seems to me that using a different domain for cron jobs causes pain with no 
gain.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] unconfined_cronjob_t et al

[Russell Coker]

On Thu, 18 Aug 2011, Russell Coker <russell@coker.com.au> wrote:
> Is there any reason why I shouldn't just unilaterally remove them from the 
> Debian policy for Squeeze regardless of what Red Hat and upstream are
> doing?

Sorry I meant to say Wheezy not Squeeze.  I'm not making big changes for 
Squeeze.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] unconfined_cronjob_t et al

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/18/2011 03:31 AM, Russell Coker wrote:
> Is anyone actually making use of domains such as
> unconfined_cronjob_t?
> 
> Is there any reason why I shouldn't just unilaterally remove them
> from the Debian policy for Squeeze regardless of what Red Hat and
> upstream are doing?
> 
> It seems to me that using a different domain for cron jobs causes
> pain with no gain.
> 

I don't think so.  I believe cronjobs in Red Hat os's are running
cronjobs as the usertype.  I would say this should just be removed.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5OOxkACgkQrlYvE4MpobMmlACcCDzLvpMW7LQ+BQPcxQtMrgYR
hsUAoNehIAV+dNUWPtI0tAEAyHrfk2bn
=xqvS
-----END PGP SIGNATURE-----

[refpolicy] unconfined_cronjob_t et al

[Christopher J. PeBenito]

On 08/19/11 06:29, Daniel J Walsh wrote:
> On 08/18/2011 03:31 AM, Russell Coker wrote:
>> Is anyone actually making use of domains such as
>> unconfined_cronjob_t?
> 
>> Is there any reason why I shouldn't just unilaterally remove them
>> from the Debian policy for Squeeze regardless of what Red Hat and
>> upstream are doing?
> 
>> It seems to me that using a different domain for cron jobs causes
>> pain with no gain.
> 
> 
> I don't think so.  I believe cronjobs in Red Hat os's are running
> cronjobs as the usertype.  I would say this should just be removed.

I don't see any objections, so I'll take a patch that eliminates the
role-derived cronjob domains, including unconfined_cronjob_t.  That
would only leave the system_cronjob_t domain for running jobs out of
/etc/cron*.  User cronjobs would run out of the user's actual domain.
The userspace files (eg default_contexts) files would need to be updated
too.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com