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
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
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:
Last Closed: 2005-06-14 17:13:39 UTC
Type: ---

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

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
% cmd2 < cmd
% 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

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

--- test.cgi is:
echo Content-Type: text/plain
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.


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