I have a CGI script to load publications from BibBase:
#!/usr/bin/perl
use LWP::UserAgent;
my $url = 'https://bibbase.org/show?bib=http://www.example.com/pubs.bib';
my $ua = LWP::UserAgent->new;
my $can_accept = HTTP::Message::decodable;
my $response = $ua->get($url, 'Accept-Encoding' => $can_accept);
print "Content-type: text/html\n\n";
print $response->decoded_content;
(This is copied from BibBase with the exception that the URL is hard-coded.)
I have three webservers running RHEL7 and Apache 2.4 that are configured the same way by Puppet. On all three I can run the script on the command line and get the expected results:
[root#server1 cgi-bin]# ./bibbase_proxy2.cgi | head
Content-type: text/html
<img src="//bibbase.org/img/ajax-loader.gif" id="spinner" style="display: none;" alt="Loading.." />
<div id="bibbase">
<script type="text/javascript">
var bibbase = {
params: {"bib":"http://www.example.com/pubs.bib","host":"bibbase.org"},
When I try to run the script with CGI, I get three different results:
Server1
Unrecognised protocol tcp at /usr/share/perl5/LWP/Protocol/http.pm line 31.
Server2
Can't connect to bibbase.org:443 System error at /usr/share/perl5/LWP/Protocol/http.pm line 51.
Server3
No http output and the error log says AH01215: Out of memory!.
I can't find anything different between the three servers and I can't figure out why the script works fine on the command line and doesn't work when run as a CGI.
I have selinux in permissive mode and it is logging the outgoing request, so I know the script gets that far:
type=AVC msg=audit(1532465859.921:331235): avc: denied { name_connect } for pid=161178 comm="perl" dest=80 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
For testing, I have set selinux to disabled and restarted the server.
SE-Linux denied the TCP connection.
avc: denied { name_connect }
The default access controls for networking by SELinux are based on the labels assigned to TCP and UDP ports and sockets. For instance, the TCP port 80 is labeled with http_port_t (and class tcp_socket). Access towards this port is then governed through SELinux access controls, such as name_connect and name_bind.
When an application is connecting to a port, the name_connect permission is checked. However, when an application binds to the port, the name_bind permission is checked.
Permissive mode or not, Perl is acting like it was denied a TCP connection. Unrecognised protocol tcp means getprotobyname("tcp") failed inside IO::Socket::IP. That's very, very unusual. One of the ways that can happen is via exactly that SELinux denial.
I'm no SELinux expert, but according to RedHat and Gentoo some SELinux aware applications will ignore the global permissive setting and go it alone. RHEL 7 Apache appears to be one of them. It appears to have its own domain which must be set permissive.
On all three I can run the script on the command line and get the expected results:
There's two reasons for that, and they both have to do with users.
When you run the program you're running as your own user with your own configuration, permissions, and environment variables. In fact, you ran it as root which usually bypasses restrictions. When it runs on the server it runs as a different user, probably the web server user with severe restrictions.
In order to do a realistic test, you need to run it as the same user the web server will. You can use sudo -u for this. For example, if the user is apache...
sudo -u apache ./bibbase_proxy2.cgi
BTW Do not test software as root! Not only is it not going to give you sensible results, but if there's a bug in the software there are no safeguards preventing it from wrecking your system.
The second problem is #!/usr/bin/env perl. That means to run whatever perl is in your PATH. PATH will be different for different users. Running ./bibbase_proxy2.cgi may run with one Perl on the command line and a different one via the web server.
In a server environment, use a hard coded path to Perl like #!/usr/bin/perl.
We tested by rewriting the same script in Python and PHP. Both of them showed error which pointed us in the right direction.
Python urllib2 produced the error
<class 'urllib2.URLError'>: <urlopen error [Errno 16] Device or resource busy>
args = (error(16, 'Device or resource busy'),)
errno = None
filename = None
message = ''
reason = error(16, 'Device or resource busy')
strerror = None
PHP (run as CGI) wouldn't even start:
[Wed Jul 25 15:24:52.988582 2018] [cgi:error] [pid 10369] [client 172.28.6.200:44387] AH01215: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/curl.so' - libssh2.so.1: failed to map segment from shared object: Cannot allocate memory in Unknown on line 0
[Wed Jul 25 15:24:52.988980 2018] [cgi:error] [pid 10369] [client 172.28.6.200:44387] AH01215: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/dba.so' - libtokyocabinet.so.9: failed to map segment from shared object: Cannot allocate memory in Unknown on line 0
---- Similar lines for all extensions. ----
It appears that RLimitMEM blocks access to shared memory and that is required for opening sockets. I can't find any documentation, but removing that line makes it work.
Related
I am trying to use an auto reply program for one of the users.
It works fine when I have user email address defined in .forward file but it gives following error when I put it in script:
Jun 28 12:25:38 localhost sendmail[5210]: s5SJPFkN005208: to="|/home/alpha/autoreply.pl", ctladdr=alpha#localhost (501/501), delay=00:00:10, xdelay=00:00:00, mailer=prog, pri=60446, dsn=5.0.0, stat=Service unavailable
Jun 28 12:25:38 localhost sendmail[5210]: s5SJPFkN005208: s5SJPckN005210: DSN: Service unavailable
Do I have have make any changes in sendmail configs (i.e. symbolic link etc)?
Thanks.
1.Have you checked problems mentioned in sendmail FAQ?
Sendmail-FAQ-3.11: Why can't my users forward their mail to a program?
2. On most linuxes sendmail uses procmail as local mailer program.
You may try to execute your script from ~/.procmailrc of the user.
The issue was /etc/smrsh did not have symbolic link for perl which can be defined as
ln -s /usr/bin/perl /etc/smrsh/perl
Whenever I run a simple send email function using Email::Send::Gmail I get this error:
[Mon Jan 28 11:37:57 2013] [error] [client 31.171.245.] Error sending email: Email::Send::Gmail: error connecting to server smtp.gmail.com at /usr/local/share/perl5/Email/Send.pm line 252, referer: http://**.cgi
However, exact same code is working when run from command line. And smtp.gmail.com is available when telneting from command line. It this because of the persistence or am I missing something?
Alrgiht, I got it. Seems selinux on CentOS was blocking outside connections from httpd, thus the script was not connecting.
You need to enter this
setsebool -P httpd_can_network_connect=1
In order to connect.
Try (in your cgi script) doing this:
use Net::SMTP::SSL;
Net::SMTP::SSL->new( 'smtp.gmail.com', Port => 465, Debug => 1 );
and see if the debugging information tells you anything helpful.
Is it possible that your cgi script is using a different perl, with different modules installed?
I'm using "Net::SFTP" in perl cgi file to put files to a windows M/C from my dev box.
After adding below new directory manually (with 0777 permissions) everything works fine:
bash-4.1$ pwd
/.ssh
-bash-4.1$ cd ..
-bash-4.1$ ls -ltra | grep .ssh
drwxrwxrwx 2 root root 4096 Jan 23 23:57 .ssh
Problem (if I don't add above directory manually ) here is as per my understanding:
Apache is running cgi with user as "nobody" which do not have permissions to make directory after connection is established via sftp and I'm getting below error messages in logs:
xxx.xxx.net: Reading configuration data /.ssh/config
xxx.xxx.net: Reading configuration data /etc/ssh_config
xxx.xxx.net: Connecting to xxx.xxx.xxx.com, port 22.
xxx.xxx.net: Remote protocol version 2.0, remote software version 5.17 FlowSsh: Bitvise SSH Server (WinSSHD) 5.58: free only for personal non-commercial use^M
Math::BigInt: couldn't load specified math lib(s), fallback to Math::BigInt::Calc at /usr/lib/perl5/site_perl/5.8.8/Crypt/DH.pm line 6
xxx.xxx.net: Net::SSH::Perl Version 1.34, protocol version 2.0.
xxx.xxx.net: No compat match: 5.17 FlowSsh: Bitvise SSH Server (WinSSHD) 5.58: free only for personal non-commercial use^M.
xxx.xxx.net: Connection established.
xxx.xxx.net: Sent key-exchange init (KEXINIT), wait response.
xxx.xxx.net: Algorithms, c->s: 3des-cbc hmac-sha1 none
xxx.xxx.net: Algorithms, s->c: 3des-cbc hmac-sha1 none
xxx.xxx.net: Entering Diffie-Hellman Group 1 key exchange.
xxx.xxx.net: Sent DH public key, waiting for reply.
xxx.xxx.net: Received host key, type 'ssh-dss'.
xxx.xxx.net: Permanently added 'xxx.xxx.xxx.com' to the list of known hosts.
**mkdir //.ssh: Permission denied at /usr/lib/perl5/site_perl/5.8.8/Net/SSH/Perl/Util/Hosts.pm line 92**
I tried to solve this problem with different methods given over internet but nothing is working for me.
Can anybody suggest possible solution?
Any help will be greatly appreciated.
I recently ran into the same problem myself and you are correct that it is a permissions issue. When your nobody process tries to connect to the remote server, it wants to write the remote host key to a file. This is the step that is failing in your error message (Hosts.pm line 92).
My solution was to create a nobody-writable location for the NET::SFTP to write the known_hosts file and to specify that location before you construct your NET::SFTP connection.
$ENV{HOME} = '/nobody/writable/location/';
You can find more information on this problem at http://www.perlmonks.org/?node_id=599078
I am trying to use the function mail in a server over windows with iss7 and i am getting this warning which doesn't let me send mails:
Warning: mail(mail.log): failed to open stream: Permission denied in xxxx
That line is:
mail("mail#myserver.com", "subject", 'body',"From: mail2#myserver.com")
At php.ini i have configured SMTP server, port and sendmail_from like this:
; http://php.net/smtp
SMTP = 128.x.x.xxx
; http://php.net/smtp-port
smtp_port = 110
; For Win32 only.
; http://php.net/sendmail-from
sendmail_from = mymail#myserver.com
; The path to a log file that will log all mail() calls. Log entries include
; the full path of the script, line number, To address and headers.
mail.log = mail.log
I have also created a file called "mail.log" inside C:/php/ and i have changed permissions to write and read for all users.
Also, at phpinfo() safe_mode is Off.
I am currently sending mails with PHPMailer but it is soooo slow that i want to try it with mail function.
Do you know what am I doing wrong?
Thanks.
You should have a mail.log entry in your php.ini file which should log all the mail() function calls. Search for it and if you don't have this line, then it's taking some strange default or previously defined value, so you better define it and point it to the file you have created in your PHP folder and hopefully assigned good permissions to. For more check what phpinfo() is saying about mail.log.
For more info: mail configuration.
Line 271 from HTTP::Proxy is this:
my $daemon = HTTP::Daemon->new(%args) or die "Cannot initialize proxy daemon: $!";
When I try to run this script:
use CGI;
use CGI::Carp(fatalsToBrowser);
use HTTP::Proxy;
my $proxy = HTTP::Proxy->new( port => 8080 ); # Edit: I have tried other ports, too, including 3123, 32789, etc.
$proxy->start;
I get this error message from the browser:
Software error:
Cannot initialize proxy daemon: Operation not permitted at HTTP/Proxy.pm line 271.
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
I assume this is because I need root permission. Are there any ports I can use that don't require root permission? I don't have the root password to the server.
Edit: Apparently I'm supposed to be able to start it without root with 1025 or greater. How would I set up a stacktrace?
You can use any port (that is not already in use) above 1025. If you are getting that message in your browser (on port 8080?), your daemon is already successfully using that port. I'm not sure what other permission issues it might entail. You could check the documentation or try strace