So, lurking somewhere deep in MIME::Parser, there’s a tainting error
that I can’t isolate it. After running for a day or two, my development
RT instances running setgid fastcgi do seem to hit it. The only reason
we’re running in taint mode in the first place is because the fastcgi
handler is setgid so that it can read the RT configuration file.
In this day and age, there are better solutions for allowing the RT
handler to be executed as the RT user. I’m strongly considering
making the fastcgi handler a normal perl script and recommending that
folks use apache SuExec or equivalent. Anyone have a good reason that
the current setup works better?
In this day and age, there are better solutions for allowing the RT
handler to be executed as the RT user. I’m strongly considering
making the fastcgi handler a normal perl script and recommending that
folks use apache SuExec or equivalent. Anyone have a good reason that
the current setup works better?
It should also be noted that the existing setup just doesn’t work on Mac
OS X and other operating systems that haven’t explicitly disabled set-id
scripts in the kernel.
So, lurking somewhere deep in MIME::Parser, there’s a tainting error
that I can’t isolate it. After running for a day or two, my
development
RT instances running setgid fastcgi do seem to hit it. The only reason
Well, personally, I think that one should always run with taint mode
on any program exposed to public humiliation^W user input.
Particularly web sites and things that handle incoming email.
But if you can’t track down the error, that makes life quite
difficult… 
smime.p7s (2.42 KB)
Well, personally, I think that one should always run with taint mode
on any program exposed to public humiliation^W user input.
Particularly web sites and things that handle incoming email.
If perl’s taint mode allowed us to specify which data sources were
tainted, it would be another matter entirely. And if CPAN module authors
routinely dealt with code run under taint mode, it would be worth
considering. But as it is, -T is somewhat of a red-headed step-child.
So, lurking somewhere deep in MIME::Parser, there’s a tainting error
that I can’t isolate it. After running for a day or two, my development
RT instances running setgid fastcgi do seem to hit it. The only reason
we’re running in taint mode in the first place is because the fastcgi
handler is setgid so that it can read the RT configuration file.
In this day and age, there are better solutions for allowing the RT
handler to be executed as the RT user. I’m strongly considering
making the fastcgi handler a normal perl script and recommending that
folks use apache SuExec or equivalent. Anyone have a good reason that
the current setup works better?
The only point of taint mode is to make it harder, not
impossible, to shoot your own foot. If you develop RT using
taint mode to help you find those places that would benefit
from input validation, and you do the right thing, then there
is no additional benefit to running taint mode in production.
(Unless, of course, the local admin modifies the code 
I personally have a dedicated apache instance for RT,
and I just set the group of the server to ‘rt’, and that
avoids exactly this taint problem. Another option is to
supply a tiny C wrapper that is, itself, suid root.
Its whole purpose is to change egid and rgid to ‘rt’
and then exec the fastcgi handler. I believe, if
egid==rgid, perl will not turn on taint mode.
Another option is to run the fastcgi by hand, and not
have the apache server manage it.
bobg
I personally have a dedicated apache instance for RT,
and I just set the group of the server to ‘rt’, and that
avoids exactly this taint problem. Another option is to
supply a tiny C wrapper that is, itself, suid root.
Well, we don’t need that much rope. Just setgid ‘rt’ 
But apache’s “suexec” functionality can do this for end-users without
needing to do a custom build for RT.
Its whole purpose is to change egid and rgid to ‘rt’
and then exec the fastcgi handler. I believe, if
egid==rgid, perl will not turn on taint mode.
Correct.
This is pretty interesting for me as i run RT on MacOSX with FastCgi and
couldn’t manage to run rt setgid.
So now i just gor Suexec support for apache going.
Do you have a sample apache configuration as to how to call the Mason
Handler setgid using the apache suexec feature?
No, but with luck, I will within the next day or so.
Do you have a sample apache configuration as to how to call the Mason
Handler setgid using the apache suexec feature?
No, but with luck, I will within the next day or so.
Great! Looking forward to that.
http://www.StefanSeiz.com
Spamto: bin@imd.net
Do you have a sample apache configuration as to how to call the Mason
Handler setgid using the apache suexec feature?
No, but with luck, I will within the next day or so.
It’s worth mentioning that apple doesn’t bundle suexec with their
apache.
It’s worth mentioning that apple doesn’t bundle suexec with their
apache.
Yes. As I see things, they compiled Apache with SUEXEC support but do not
include the suexec wrapper. So I had to download the apache source and just
compiled the suexec wrapper. Seems to work according to:
root# httpd -l
Compiled-in modules:
http_core.c
mod_so.c
suexec: enabled; valid wrapper /usr/sbin/suexec
When compiling suexec, I made sure to include /opt/rt3/bin in to the suexec
path and set /opt/rt3/share/html as the document root besides taking care
about minimum gid/uid. I hope that was correct.
http://www.StefanSeiz.com
Spamto: bin@imd.net
When compiling suexec, I made sure to include /opt/rt3/bin in to the suexec
path and set /opt/rt3/share/html as the document root besides taking care
about minimum gid/uid. I hope that was correct.
I did a similar thing with FC1 when I recompiled from the SRPM. I
would have prefered a method of using suexec that didn’t involve
recompiling apache, but I didn’t have time to experiment when I was
running into the Locale::Maketext::Guts.pm error.
Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
RT 3.1.17 is a new snapshot release that’s now available from:
http://download.bestpractical.com/pub/rt/devel/rt-3.1.17.tar.gz
It contains numerous small cleanups and fixes relative to RT 3.1.16.
It also no longer makes use of perl’s SetGID support.
Draft updated instructions for FastCGI configuration options are on the
Wiki at Request Tracker Wiki.
I would greatly appreciate commentary either on this list or on the
Wiki as soon as folks can get to it. To my knowledge, getting this
solved will allow an immediate release candidate of RT 3.2.
Best,
Jesse
So how does your Virtual Host Apache Directive (httpd.conf) look for your
RT-with-SuExec setup?
Apache2/suexec are compiled with -D AP_DOC_ROOT=“/opt/rt3”.
SuexecUserGroup rt rt
FastCgiWrapper /usr/sbin/suexec
FastCgiIpcDir /var/run/httpd/fastcgi
FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 3600 -processe
s 4 -init-start-delay 30 -user rt -group rt
FastCgiConfig -minProcesses 5 -killInterval 120
NameVirtualHost *:8080
<VirtualHost *:8080>
ServerName noc-eng-rt:8080
DocumentRoot /opt/rt3
AddDefaultCharset UTF-8
Alias /NoAuth/images /opt/rt3/share/html/NoAuth/images
<IfModule mod_fastcgi.c>
AddHandler fastcgi-script fcgi
ScriptAlias / /opt/rt3/bin/mason_handler.fcgi/
</IfModule>
/opt/rt3/bin, etc/, and lib/ are owned rt:rt as is /opt/rt3/var/mason_data.
HTH,
Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
Draft updated instructions for FastCGI configuration options are on the
Wiki at Request Tracker Wiki.
I would greatly appreciate commentary either on this list or on the
Wiki as soon as folks can get to it. To my knowledge, getting this
solved will allow an immediate release candidate of RT 3.2.
I believe that for suexec you can use a hard link in addition to
copying the FastCGI handler into the docroot. I haven’t tested since I
recompiled apache instead.
Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
At 09:48 AM 6/18/2004, Michael S. Liebman wrote:
SuexecUserGroup rt rt
FastCgiWrapper /usr/sbin/suexec
FastCgiIpcDir /var/run/httpd/fastcgi
FastCgiServer /opt/rt3/bin/mason_handler.fcgi -idle-timeout 3600
-processe
s 4 -init-start-delay 30 -user rt -group rt
FastCgiConfig -minProcesses 5 -killInterval 120
Obviously this closing an unopened was superfluous.
Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”
Jesse Vincent a écrit :
Draft updated instructions for FastCGI configuration options are on the
Wiki at Request Tracker Wiki.
I would greatly appreciate commentary either on this list or on the
Wiki as soon as folks can get to it. To my knowledge, getting this
solved will allow an immediate release candidate of RT 3.2.
Best,
Jesse
Hello,
I’m running RT 3.0.10 in a Apache2 / Suexec / FastCGI config on a Fedora
Core 1 box. RT is installed in /home/rt3.
The “SuexecUserGroup” directive is required along with “-user” and
“-group” options of “FastCgiServer” for Apache 2. Here’s my setup
pertaining to FastCGI :
SuexecUserGroup rt rt
FastCgiServer /var/www/rt3-bin/mason_handler.fcgi -user rt -group rt
ScriptAlias /rt/ /var/www/rt3-bin/mason_handler.fcgi/
<Directory /var/www/rt3-bin/mason_handler.fcgi/>
SetHandler fastcgi-script
order deny,allow
allow from all
Furthermore:
- the handler should be in a directory owned by the specified user and
group – in fact, I could not manage to get it runnning with doing it,
- the handler should NOT be setuid/setgid.
So I set up files this way :
mkdir /var/www/rt3-bin
ln /home/rt3/bin/mason_handler.fcgi /var/www/rt3-bin/
chown rt:rt /var/www/rt3-bin /home/rt3/bin/mason_handler.fcgi
chmod 0555 /var/www/rt3-bin /home/rt3/bin/mason_handler.fcgi
Best regards,
Guillaume Perréal.
Responsable informatique,
Cemagref, groupement de Lyon,
France.
Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/