Bug 160296

Summary: No output from program when run from cgi-bin directory from command-line
Product: [Fedora] Fedora Reporter: Stuart Reynolds <stuart.reynolds>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-14 17:13:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stuart Reynolds 2005-06-14 08:01:34 UTC
Description of problem:

[Following on from bug 138767, which was closed]
Programs fail to execute is bizarre, unexpected and confusing ways when run from
the command-line if they reside in cgi-bin directories.

% ~/test.cgi  # OK
Content-Type: text/plain

CGI scripts work
% mv test.cgi ~/public_html/cgi-bin/
% chmod -R go+rx ~
% ~/public_html/cgi-bin/test.cgi  # Fails - no output
% cd ~/public_html/cgi-bin 
% test.cgi       # Fails -  no output
% setenforce 0
% test.cgi       # Success!!!
Content-Type: text/plain

CGI scripts work
% setenforce 1
% test.cgi          # Fails - no output. Bah!
% test.cgi | cat    # Success! Why? [See 138767]
Content-Type: text/plain

CGI scripts work
% #
% # More bizarrely:
% #
% test.cgi && echo OK    # Fails to return error !!! -- echo executes
OK

This last one just looks like a bug. I'm guessing the program failed to execute
due to permission problems that I don't understand - surely I should get an
error code and an error message. The lack of reasonable feeback makes this looks
like a bug to me.

Also, run, the follow, it :
% sh < test.cgi     # Runs fine!
Content-Type: text/plain

CGI scripts work
% test.cgi | sh     # Runs sh on the output (which could be malicious!)
sh: line 1: Content-Type:: command not found
sh: line 3: CGI: command not found

Basically, the distinction between

% cmd
and
% cmd2 < cmd
or
% cmd | cmd2

is far too subtle to me. If the first is not permitted, why should the second
and third. Looks like a bug to me, even is bug 138767 says its a feature.


Version-Release number of selected component (if applicable):

Fedora core 3

How reproducible:


---- Setup: -----

All files and directories up to ~/public_html/cgi-bin/test.cgi
are world executable and readable. I also have:

% ls -lZ test.cgi
drwxr-xr-x  admin    admin    root:object_r:user_home_dir_t    admin

(~ == ~admin)
I've got no idea where "root" came from. File was created by doing
  "cat > test.cgi"

(as the admin user)

chcon'ing test.cgi and the parents directorys to any combination of:
   user_t, httpd_sys_content_t, httpd_sys_script_exec_t
doesn't seem to help though.

Trying to get root to execute ~admin/public_html/cgi-bin/test.cgi
also fails (with no output).

Redoing all of the above as a different user to "admin" also fails with no output.


--- http.conf contains:
<IfModule mod_userdir.c>
    UserDir public_html
</IfModule>

<Directory /home/*/public_html/cgi-bin>
   Options ExecCGI
   SetHandler cgi-script
</Directory>

--- test.cgi is:
#!/bin/sh
echo Content-Type: text/plain
echo
echo "CGI scripts work"

Comment 1 Daniel Walsh 2005-06-14 17:13:39 UTC
This is a problem in policy in FC3, which should be fixed in FC4.  A workaround
is to pipe to cat.

Basically what is happening is the cgi script is transitioning to
httpd_sys_script_t, which is not allowed to talk to the TTY.  This is a security
meassure to prevent the cgi script from fooling a user.  In FC4 the transition
should only happens from httpd_t not from unconfined_t.

Policy allows for commincating with pipes so the script is allowed to write to
the "cat" pipe and cat is running under unconfined_t so it has access to the TTY.

Dan