No perl cgi scripts working

nobaloney

nobaloney

NoBaloney Internet Svcs - In Memoriam †
Joined
Jun 16, 2003
Messages
26,113
Location
California
On a new server installation:

CentOS 6.4 (Final), DA 1.44.0, Custombuild 2, mod_ruid2

Perl scripts don't work:

http://www.nobaloney.net/cgi-bin/environment.pl

The script runs fine from the command line, and CGI is turned on.

shell cgi scrits work fine:

http://www.nobaloney.net/cgi-bin/da_test.cgi

and the shell id returns:
Code: 
uid=782(nobaloneyn) gid=782(nobaloneyn) groups=782(nobaloneyn),503(apache),506(access)

In my /etc/httpd/conf/extra directory I've got two directory configurations:

httpd-directories-new.conf
and
httpd-directories-old.conf

And httpd-directories.conf is a link to httpd-directories-old.conf.

Browser error is:
Code: 
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to
complete your request.

Please contact the server administrator at [email protected] to inform
them of the time this error occurred, and the actions you performed just before
this error.
More information about this error may be available in the server error log.
and the server log error is:
Code: 
[Wed Oct 23 16:06:19.551812 2013] [cgi:error] [pid 3953] [client 97.90.180.18:50238]
AH01215: (13)Permission denied: exec of
'/home/nobaloneyn/domains/nobaloney.net/public_html /cgi-bin/environment.pl' failed
[Wed Oct 23 16:06:19.555299 2013] [cgi:error] [pid 3953] [client 97.90.180.18:50238] End of
script output before headers: environment.pl
Any help in resolving this problem is very much appreciated.

Thanks.

Jeff
 
What are the file permission on environment.pl? It should be 755, so if it is not, then change it and see if it helps ...
 
Last edited:
Can you rename environment.pl to environment.pl.txt and add it as a attachement in a reply in this forum? Then I can download it, and see if it works on my servers, or not?
 
Simple enough to just put inline:
Code: 
#!/usr/bin/perl
##
##  printenv -- demo CGI program which just prints its environment
##

print "Content-type: text/plain\n\n";
foreach $var (sort(keys(%ENV))) {
    $val = $ENV{$var};
    $val =~ s|\n|\\n|g;
    $val =~ s|"|\\"|g;
    print "${var}=\"${val}\"\n";
}

It can also be found in my download system at:

http://nobaloney.net/downloads/environment/environment.pl.txt

Jeff
 
I tested the .pl file on one of my servers (running cb 2.0 and mod_ruid2), and I also get a error:

Code: 
500 Internal Server Error
 
I found an error in my copy/paste There should be a closing bracket. I've fixed it above. If you've tested it with a copy/past from above, then please try again with the corrected code.

It's an ordinary perl file and it should run fine. It runs from the command line. I'm going to try it in older servers.

Please try it from the command line and on older servers if you can. It worked a few years ago on DirectAdmin powered servers and I'm going to try it elsewhere to see if it still works.

Thanks.

Jeff
 
I have now replaced the code with the missing bracket. But I still get 500 internal server error. Here is from my apache error log, I have removed my ip and domain:

Code: 
[Thu Oct 24 21:23:07.383529 2013] [cgi:error] [pid 6023] [client xx.xxx.xx.xx:53025] AH01215: (2)No such file or directory: exec of '/home/USER/domains/DOMAIN.COM/public_html/cgi-bin/environment.pl' failed
[Thu Oct 24 21:23:07.384401 2013] [cgi:error] [pid 6023] [client xx.xxx.xx.xx:53025] End of script output before headers: environment.pl
[Thu Oct 24 21:23:07.384645 2013] [include:warn] [pid 6023] [client xx.xxx.xx.xx:53025] AH01374: mod_include: Options +Includes (or IncludesNoExec) wasn't set, INCLUDES filter removed: /500.shtml

However I have customers that is running MovableType (uses perl), wich do not have problems. So it is strange.
 
Yes, strange for me, as well. I have a client reporting a problem with a perl script since we moved him to this newly configured server. I don't know anything about his script, so I tried with mine. It doesn't work either as you can see.

John has checked this server previously for me because of a cgi-issue (which turned out to be that the cgi-script was 32-bit compiled and this is a 64-bit server), so I've asked John to look at this thread when he has a chance, and I'll keep away from it until then :) .

Jeff
 
Hi Jeff,

Check:
Code: 
ls -la /usr/bin/perl
as I know we do a chmod 705 root:apache in some cases.
It might need 755.

John
 
That was it. It works :D!

Is this a bug? Does it need to be changed to 755 for perl scripts to be able to work? It would appear so.

If so, can you make it a default? Or should I add it to my notes for future installs?

Thanks.

Jeff
 
As you can see in my replies, I have tested nobaloney environment.pl file too, and it does not work on my servers.

I checked two of my production servers, wich both the environment.pl does not work on. One of the servers has /usr/bin/perl set to 705 root apache, and the other is set to 755 root root:

Code: 
[root@server1 ~]# ls -la /usr/bin/perl
-rwx---r-x 2 root apache 6912 Apr 30 14:25 /usr/bin/perl

[root@server2 ~]# ls -la /usr/bin/perl
-rwxr-xr-x 2 root root 6912 Apr 30 14:25 /usr/bin/perl

I am not happy about the difference, and it make me unsure about everything. The server with 755 root root, is a server previous upgraded to cb 2.0. The other one is newer and was installed with cb 2.0 from start. Both servers is CentOS 6.4 64 bit, with cb 2.0 and mod_ruid2. Both of them do not work with nobaloney script.

They are shared hosting servers in production. I would like to know what the owner group and permissions should be, and if it is safe?
 
As you can see, I asked a similar question a moment before you did.

755 root:apache will work; the apache user needs access to perl. And apache's primary group is also apache, so that's the tightest ownership/permission pair which will allow perl scripts to run.

And as you note yourself, 755 root:root won't work, of course, because apache is not (and should never be) a member of the root group.

Thanks, ditto. Thanks John.

Jeff
 
I changed one of my servers /usr/bin/perl, wich before was 0705, I changed it to 0755, but environment.pl still give:

500 Internal Server Error
 
I believe this, once released, should fix it:
http://www.directadmin.com/features.php?id=1514

which would allow us to leave perl in it's more secure state of preventing the apache group.
I don't think we should be seeing apache and access in the groups.
It was added to the templates way back before we had it included with DA, so it wasn't given much thought, but we shouldn't need it.

John
 
To clarify, the lack of this setting in no way allows someone to enter the server.
It simply prevents the running of scripts in some situations, which shouldn't typically happen anyway.
It's really an optional increase in security, but isn't required by any means.

----

The perl root:apache 705 change is only there to handle any cases were a hacker somehow is able to run scripts through apache, when they're not supposed to.. but assumes they're already on the box through apache somehow.
This shouldn't include cgi-bin scripts (current bug/issue), but would include php scripts that make system() calls to perl, if php runs as CLI (as "apache")

mod_ruid2 should be running as the User, and shouldn't have apache in the group.. which is the point of this change:
http://www.directadmin.com/features.php?id=1514

So the issue where using mod_ruid2 can't run perl is due to the id=1514 bug, where apache and access shouldn't be added.

Setting perl to 755 is not "insecure" perse (if they're already in, they've got plenty of other things they can do), but locking it down to prevent apache from running it may help in some rare hacking cases, in the event that their specific hacking script needs perl.
If they break in in any other case, it will simply mean their hacking script runs as the user, instead of apache.

So you've got 2 solutions:
1) Set perl to 755.. easy, no harm done.
2) Update to the pre-release DA binaries or manually just change your current data/templates/virtual_host2* templates to remove the RGroups option. (the DA update will give you the same templates anyway)

John
 
Thanks. But I really need it black in white. My servers was having perl set in different ways, I have now set all my servers to number 1 (see below).

For best security (but perl need to work for clients cms), wich of the 3 below should I choose to set /usr/bin/perl ?

1:
group: apache
owner: root
permission: 0755

2:
group: apache
owner: root
permission: 0705

3:
group: root
owner: root
permission: 0755

When DA 1.441 is released, is it needed with any manual action regarding this http://www.directadmin.com/features.php?id=1514 ?

Edit: fixed typo in owner/group on number 1 and 2
 
Last edited:
You must log in or register to reply here.
Back
Top