When fixing bug #1382514, I found out that CGI scripts started from httpd24-httpd-2.4.18-11.el7.x86_64 are missing LD_LIBRARY_PATH environment variable set when enabling a collection registered in /opt/rh/httpd24/service-environment.
(1) Install httpd24-httpd and rh-perl524-perl.
(2) Register rh-perl524 collection in /opt/rh/httpd24/service-environment.
(4) Start httpd24-httpd service.
(3) Create this CGI script:
# cat /opt/rh/httpd24/root/var/www/cgi-bin/test
(4) Retrieve <http://localhost/cgi-bin/test> document.
Current behavior is the "set" command reports rh-perl524 executable paths in PATH, but it does not report LD_LIBRARY_PATH variable. As a result the "perl -v" command from the CGI script fails and httpd error_log will contain:
[cgi:error] [pid 3807] [client ::1:49436] AH01215: perl: error while loading shared libraries: libperl.so.rh-perl524-5.24: cannot open shared object file: No such file or directory: /opt/rh/httpd24/root/var/www/cgi-bin/test
In my opinion, if httpd24-http support collections, it should pass LD_LIBRARY_PATH into CGI scripts. Otherwise it's not possible to use interpreters from registered collections. Actually it should pass any variable set when enabling a collection.
I tried to put "PassEnv LD_LIBRARY_PATH" on various places, but without success. It will never show in the environment. While "SetEnv FOO BAR" written on next line in the httpd configuration works.
It looks like the LD_LIBRARY_PATH is handled specially in mod_cgi. If I add these directives into /opt/rh/httpd24/root/etc/httpd/conf/httpd.conf to pass all variable set when enabling rh-perl524 (scl enable rh-perl524 '/usr/bin/env | grep rh-perl | sort'):
Then all of them except LD_LIBRARY_PATH will be passed. I guess mod_cgi treats LD_LIBRARY_PATH specially. And all of that despite mod_env documentnation <http://httpd.apache.org/docs/current/mod/mod_env.html#passenv>.
I suspect httpd to execute a CGI script via /sbin/suexec that is SUID, so ld-linux.so will ignore the LD_LIBRARY_PATH when linking /sbin/suexec. But in addition it will remove the variable from the environment, thus /sbin/suexec's child, the CGI script, will miss the LD_LIBRARY_PATH variable.
If you could not find a proper fix, we would have to rebuild all collections to use RPATH in all of their ELF executable programs.
How were you enabling perl524 in service-environment, Petr?
I can't reproduce this, vanilla httpd.conf.
[root@virt-el7sclY ~]# grep -v ^# /opt/rh/httpd24/service-environment
[root@virt-el7sclY ~]# rpm -q httpd24-httpd
[root@virt-el7sclY ~]# rpm -V httpd24-httpd
[root@virt-el7sclY ~]# curl -s http://localhost/cgi-bin/ptest | grep LD_LI
The special case in httpd is to ensure specifically that LD_LIBRARY_PATH *is* passed through to CGI scripts as-is.
You're right the suexec case will fail to pass through LD_LIBRARY_PATH, though, but suexec is *not* used by default (and is relatively rare these days). I know some people patch suexec to allow passing LD_LIBRARY_PATH... not sure what the right thing is there.
I have the same versions as you and I have the very same line as you in the /opt/rh/httpd24/service-environment.
I purged all the SCL packages and the /opt directory, installed packages the script and the service-environment again, and I still can reproduce it. I will try it again in a different virtual machine.
Hmmm, weird. Can you check whether LD_LIBRARY_PATH is set in one of the httpd child processes when httpd24-httpd is running via /proc/XXXX/environ?
Ah ha. I had SELinux permissive mode on for httpd_t. Without permissive mode, I can reproduce.
I believe this is a deliberate result of SELinux policy, which clears LD_LIBRARY_PATH across the domain transition when the CGI script is exec'd (setting the "AT_SECURE" flag).
I'm not totally sure this is an appropriate default for the httpd_t->httpd_sys_script_t transition *for the httpd24 SCL*, but we don't have separate SELinux policy for httpd in RHSCL to base-RHEL.
It's one line of policy to over-rule this, and this isn't something people are hitting frequently (I guess), just documenting it is an option.