Hi Russ, Colin, and all,
--On Sunday, August 15, 2004 2:03 AM -0400 Colin Walters <walters@xxxxxxxxxx> wrote:
Actually I think this is the same problem as the "crond/mailman" thread just above :)
Yes, I believe that the new thread appeared after I'd searched for messages. But, perhaps my search was less effective than I'd hoped <g>.
However, the exe name associated with such scripts is /usr/bin/python2.3, rather than the name of the script.
You mean that you see exe=/usr/bin/python2.3 in the audit logs? That's just a side effect of the way the kernel interprets the #! header and executes the script, it doesn't mean all python scripts have to run in the same domain.
Ah! I hadn't considered that the behavior of a python script using a shebang (#!) and one invoking python with a script name as a an argument might differ. The distinction is obvious in retrospect. Part of my confusion arose because one of my files was incorrectly labeled. As someone wrote, it's not what you don't know that gets you, it's what you think you know that isn't really so <g>.
I don't think it's necessary to modify run-parts. Instead, inside the definition of your foo_script.te file, do something like:
ifdef(`crond.te', ` system_crond_entry(foo_script_exec_t, foo_script_t) ')
Thanks! I hadn't noticed that convenient macro. FYI, it looks like its definition already checks for crond.te:
# When system_crond_t domain executes a type $1 executable then transition to
# domain $2, allow $2 to interact with crond_t as well.
define(`system_crond_entry', `
ifdef(`crond.te', `
domain_auto_trans(system_crond_t, $1, $2)
allow $2 crond_t:fifo_file { getattr read write ioctl };
# a rule for privfd may make this obsolete
allow $2 crond_t:fd use;
allow $2 crond_t:process sigchld;
Cheers,
-- Bill McCarty, Ph.D. Professor of Information Technology Azusa Pacific University
