Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160296 - No output from program when run from cgi-bin directory from command-line
Summary: No output from program when run from cgi-bin directory from command-line
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-14 08:01 UTC by Stuart Reynolds
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-14 17:13:39 UTC


Attachments (Terms of Use)

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


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