CGI Call Not Allowed

Tried running with security off and that didn't help.

Stripped everything out of xxxxxxx.sh file in GENDIR/cgi-bin and still get the message. Is there a new restriction on file extensions? I tried it as .exe .cgi and obviously .sh with the same results

What does it mean:
CGI application is not in allowed list of CGI appli
cations to run: /lawson/lawprod/gen/cgi-bin/xxxxxx.sh

The permissions to the file and folder are wide open.

Have you tried running the script in a directory other than /lawson/lawprod/gen/cgi-bin?

The script runs fine from the command line. Just not through portal/ming.le or more specifically thru a CGI call.

Assuming you're running IBM HTTP server [IHS]?
do you have an exec mapping rules in httpd.conf

I checked the WAS logs, see below. I believe 200 is good. Not sure about 266. WAS is still the same. Only difference was I upgrade LSF from 10.0.7 to 10.0.8. The script can be ran from the command line w/o issue.

Are you referring to the AddHandler and ExecCGI? I'm only running scripts from within the cgi-bin folder and didn't think that was necessary. Not sure which exec mappings you're referring to.

httpd.conf:
Alias /icons/ "/usr/IBM/HTTPServer/icons/"


Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all


ScriptAlias /cgi-bin/ "/usr/IBM/HTTPServer/cgi-bin/"


AllowOverride None
Options None
Order allow,deny
Allow from all






nothing in error.log and access.log had:

XXX.XX.XX.XXX - - [01/Feb/2016:16:05:55 -0500] "GET /cgi-lawson/interfa
ce_lincolnf.sh HTTP/1.1" 200 266

sorry, misdirected you.

Like Brian suggested, have you tried running from a directory outside of Lawson's control?

In other words create a ScriptAlias /cgi-dave/ "/usr/IBM/HTTPServer/cgi-dave/"
copy you .sh file there and try to execute it.

I tried various ScriptAliases and still no luck.
ScriptAlias /cgi-bin/ "/lawson/lawtest/gen/cgi-bin/"

AllowOverride None
Options None
Order allow,deny
Allow from all


Still can't figure out how it worked in 10.0.7 and in 10.0.8 it doesn't. Nothing in WAS changed.

The CGI programs work using cgi-lawson in the URL and it resolves to cgi-bin which is where the Lawson userenv.exe and printenv.exe scripts exists along with the xx.exe script. I stripped everything out of xx.exe. Basically an empty file at the moment. Security is off. The URL cgi-lawson/xx.exe is finding the file, but for some reason Lawson isn't allowing it to run. In fact I tried again using yy.exe which was a copy of userenv.exe and got the same results.

I've done everything I can to httpd.conf with no luck--Changing scriptalias etc.

The last thing I did was renamed my script to userenv.exe and it worked. For some reason the Lawson named scripts are allowed, but not my custom script names regardless of the extension. They only work when they have the same name as one of the Lawson CGI scripts.

I turned on scriptlog to capture cgi errors and I get nothing when CGI_NOT_ALLOWED occurred. The script actually doesn't run when that message occurs. I think Lawson is blocking it some how.

I kept trying to make it run as it always had in cgi-lawson which went to cgi-bin. In 10.0.8 Lawson has restricted CGI calls to it's cgi-bin directory and only allows their CGI scripts to run. See Infor's response below. So I created a new cgi-custom folder and moved my custom scripts. Added a virtual host and scriptalias for this folder in httpd.conf. Now my scripts run but they don't have any of the Lawson environment information like it used to. So I'm trying to edit the scripts so they work cleanly. Things like REMOTE_USER are gone. Not sure how to get those back.

Infor's response:

Starting 10.0.8 we have restricted the CGIs that are allowed to execute by the CGI executor web service. This list is hardcoded into the source and cannot be modified. This is in compliance with the Infor-wide security directive that, in part, aims to lock down services with ‘open-ended’ features like this one. Allowing it to execute any executable or script from the command line was a security breach and we closed it.

Lastly, this service was never meant to be used as an open ended CGI executor by clients. Its only function is to execute the CGIs that are delivered with LSF. Any other use is not supported or qualified. As an alternative, they can set up their HTTP server to execute CGIs in a separate directory for their custom scripts – away from the LSF CGIs

I was looking into this also. I couldn't find an obvious way to inject my CGIs into that list either.
I'm looking at a blackbox service to resolve my issue

Upgrading from 9.0.1.12 -> 10.0.9 and just discovered this short coming 10.0.8+.

Received the same template response from support... did it for security and never intended to be used that way (which is wrong...)

I didn't create a new virtual server, because I wasn't sure how I would call the scripts or if it matter.
So, edited the httpd.conf file and added the following entries after similar lines already in the file:

 

Need to define a new script alias directory, for our custom scripts, in httpd.conf:

ScriptAlias /ghs-cgi-bin/ "/lsf/gen/ghs-cgi-bin/"

Define the directory:NOTE: The below is surrounded by a Directory tag replace the ! with < and ? with >.  Even with CODE tags around it, it was consumed. Hungry Browser. 

!Directory /lsf/gen/ghs-cgi-bin"?

Options None
AllowOverride None
order allow,deny
Allow from all 

!/Directory?

 

We use shell scripts for cgi, so I had to define .sh extension as a CGI script via AddHandler. You probably won't need this. And I could probably rename every script with extension .cgi, but we're in Go Live crunch mode. Minimizing differences.

AddHandler cgi-script .sh

Finished with httpd.conf changes. The next step will kick everyone out of Portal and probably make Smart Office unhappy for 5 seconds.
Stop and start Apache (your directory may be different):

/was/IBM/HTTPServer/bin/apachectl stop
/was/IBM/HTTPServer/bin/apachectl start

Then need to create new ghs-cgi-bin and move scripts there. Permissions on scripts and directory MUST BE 755:

mkdir /lsf/gen/ghs-cgi-bin
mv $GENDIR/cgi-bin/ghs* $GENDIR/ghs-cgi-bin
mv $GENDIR/cgi-bin/paycheck.date.format.sh $GENDIR/ghs-cgi-bin
chmod 755 $GENDIR/ghs-cgi-bin $GENDIR/ghs-cgi-bin/*

Some of our scripts build webpages and hand them back to the calling page. Due to changes in new Apache(not sure exactly), edit scripts to insert blank line after "Content" line or as first line if content wasn't specified. Otherwise we get Internal Server Error 500, because the header must be separated from the actual text/html returned. ???

Also, creating our own CGI directory, the scripts are executed as nobody (group nobody). This caused some issues accessing data directories, etc. You can set Apache to run as a privileged user, but that seems more dangerous than opening permissions on a few directories.

Bonus: In 9.0, we used ActiveXObject to call scripts, from portal web pages. Good in 9.0, IE 7 only world. Replaced these with XMLHttpRequest objects.


I doubt this is the best way to do it, but our GO Live schedule didn't account for this vendor created speed bump...

Hope this saves someone research time,

Derek

Did anyone find a way to get REMOTE_USER back? Or to execute the userenv.exe and pull back in the results within a CGI (perl) script?