CGI script issues

Print Friendly, PDF & Email

Brian Tjaden was having some trouble with CGI scripts running on Puma and on Tempest.  Since the trouble was also on Puma, we could ignore selinux as the problem.

He could run simple CGI/Python scripts, but the trouble came when he tried to call out to another script or program from his Python script.  The error he was getting was “permission denied” The examples we worked with were hello.cgi and hello2.py.  Here’s the CGI script, after a few iterations:

#!/usr/local/bin/python2.6

import sys,os,subprocess

print ("Content-Type: text/html\n")

#os.chdir("../TargetRNA2/trash/")
#os.system("java Trash &> output.txt")
#os.system("./RNAfold -version &> output.txt")
out_file = open("/var/tmp/output.txt", "w")
os.chmod("/var/tmp/output.txt",0666)

#subprocess.call(["/usr/bin/python","./hello2.py"], stdin=None, stdout=out_file, stderr=subprocess.STDOUT)
result = subprocess.call(["/home/btjaden/public_html/cgi-bin/blastn"], stdin=None, stdout=out_file, stderr=subprocess.STDOUT, shell=Tr
ue)
#result = subprocess.call(["/home/btjaden/public_html/cgi-bin/blastn"], stdin=None, stdout=out_file, stderr=subprocess.STDOUT)
#result = subprocess.call(["/home/btjaden/public_html/cgi-bin/blastn"], stdin=None)
print "<p>",result
print "<p>euid is ",os.geteuid()
#subprocess.call(["./hello2.py"], stdin=None, stdout=out_file, stderr=subprocess.STDOUT, shell=True)
#subprocess.call(["blastn"], stdin=None, stdout=out_file, stderr=subprocess.STDOUT, shell=True)
out_file.close()

The solution to calling out to an external python script was to include the Python interpreter as the first argument.

The next problem was to call out to an external binary (ELF) file.  We got that to work on Puma by adding the shell=True keyword argument. We’re not sure why that works, but it does.

However, it didn’t work on Tempest.  Again, the error was “permission denied.”  Since the filesystems on Puma and Tempest are the same, it had to be something else.  Ah, yes, it’s SELinux.  There are a few of the log entries:

[root@tempest ~] grep denied /var/log/audit/audit.log | grep blastn | tail -3
type=AVC msg=audit(1355349606.090:272209): avc:  denied  { execute } for  pid=7945 comm="hello.cgi" name="blastn" dev=dm-4 ino=5151086 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file
type=AVC msg=audit(1355349789.856:272288): avc:  denied  { execute } for  pid=8091 comm="sh" name="blastn" dev=dm-4 ino=5151086 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file
type=AVC msg=audit(1355349789.856:272289): avc:  denied  { execute } for  pid=8091 comm="sh" name="blastn" dev=dm-4 ino=5151086 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file
[root@tempest ~]

The timestamps on these are hard to read (the number starting 1355… is the seconds since the beginning of the epoch), but there’s a program called ausearch that will also reformat them in more human-readable form:

[root@tempest cgi-bin] grep denied /var/log/audit/audit.log | grep blastn | ausearch -i --just-one
----
type=AVC msg=audit(12/12/2012 14:17:57.886:271123) : avc:  denied  { execute } for  pid=4974 comm=sh name=blastn dev=dm-4 ino=5151086 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

There are more sophisticated ways to use ausearch (different search criteria), but this is enough for now.

Since the issue is the SElinux context, and Brian’s CGI scripts can run python but not blastn, I was curious about that.  The -Z argument to “ls” lists the SElinux context:

[root@tempest cgi-bin] ls -Z /usr/bin/python ./blastn 
-rwxr-xr-x. btjaden btjaden unconfined_u:object_r:httpd_user_content_t:s0 ./blastn
-rwxr-xr-x. root    root    system_u:object_r:bin_t:s0       /usr/bin/python
[root@tempest cgi-bin]

It’s hard to know what’s critical here, but maybe setroubleshoot/sealert will help.

Alas, sealert is not helping.  It shows a denial where java is prevented from running blastn, but that isn’t what’s happening.  Very strange.  Also, the solution isn’t a simple “seboolean” kind of solution, which is what I expected.  More work is needed.

About CS SysAdmins

The CS Department System Administrators
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *