On Mon, Nov 17, 2008 at 10:34:58 -0500,
Daniel J Walsh <dwalsh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Bruno Wolff III wrote:
> On Mon, Nov 17, 2008 at 09:33:50 -0500,
> Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>> Bruno Wolff III wrote:
>>> I was making a modified version of the guest policy that needed to be able
>>> to edit and run some perl scripts that also are visible to the web server.
>>> I used the manage_files macro and allowed execute, but I can't run the
>>> script directly. But I can run it via perl.
>>> For example:
>>> [tomarndt@wolff area]$ ./newcheck.pl
>>> -bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
>> getsebool -a | grep xgues
You are trying to execute an apache script, http_sys_script_exec_t,
which is not allowed without the rule you added.
If you change the label to http_user_script_exec_t it should be able to
There doesn't seem to be a http_user_script_exec_t type. Probably it's a
typo, but I didn't see a way to get a full list and didn't manage to
guess the correct name.
I still think there is something odd about this though. I can run the perl
script using perl, just not as a script invoked from bash. I am not seeing
avc's in the audit log for these failed attempts, so I am having trouble
figuring out what is happening. Does running a bash script transition to
another context when starting from a guest context?
I tried setting each of allow_guest_exec_content and allow_xguest_exec_content
to on. (I am trying to make a modified guest policy for someone ssh'ing
in to my server.) Neither of those seemed to help.
In the short run, running 'perl newcheck.pl' instead of ./newcheck.pl isn't
really a big deal, but I'd like to try and make it work normally.