Bug 160296 - No output from program when run from cgi-bin directory from command-line
No output from program when run from cgi-bin directory from command-line
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-14 04:01 EDT by Stuart Reynolds
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-14 13:13:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stuart Reynolds 2005-06-14 04:01:34 EDT
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 13:13:39 EDT
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

Note You need to log in before you can comment on or make changes to this bug.