On Tue, Mar 05, 2013 at 01:10:38PM -1000, Camron W. Fox wrote: > On 13/02/25 6:04 AM, Kevin Falcone wrote: > > Are you sure that this perl /opt/perl/bin/perl > > > >> [cwfox@admin-new perl]$ /opt/perl/bin/perl -le 'print foreach @INC' > >> /opt/perl/lib/site_perl/5.16.2/x86_64-linux > >> /opt/perl/lib/site_perl/5.16.2 > >> /opt/perl/lib/5.16.2/x86_64-linux > >> /opt/perl/lib/5.16.2 > > > > Is the same as this perl? > > > >> /usr/local/lib64/perl5 /usr/local/share/perl5 > >> /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl > >> /usr/lib64/perl5 /usr/share/perl5 . /etc/httpd) at > > > > It looks like RT is running under /usr/bin/perl (the system perl) and > > anything you install into your custom perl will be unavailable. > > > > Disable the calendar plugin and start up RT and visit the System > > Configuration page to compare the perl -V output at the bottom to the > > results of /usr/bin/perl -V and /opt/perl/bin/perl -V > > > > Keep in mind, if you're using a packaged mod_perl you're almost > > certainly *not* using your custom built perl. > > /opt/perl/bin/perl and all the permods were installed specifically for > this RT installation. > > I installed perl 5.16.2 in /opt/perl and used it as the perl to install > everything, so how (and when) did the RT instance get hijacked? > > This pretty much sucks.
Are you using mod_perl from the system distribution? If so, it's going to use the system perl If so, you need to either use fastcgi or build mod_perl against your custom perl (which is nowhere near as hard as it was years ago, thankfully). Since you have a custom perl, you should keep in mind this announcement we made earlier today. http://blog.bestpractical.com/2013/03/security-vulnerability-in-perl.html -kevin
pgpG6zzv0ELfu.pgp
Description: PGP signature
-- RT training in Amsterdam, March 20-21: http://bestpractical.com/services/training.html Help improve RT by taking our user survey: https://www.surveymonkey.com/s/N23JW9T