Was looking at Python\Python310\Tools\demo folder and found a program called rpythond.py... This file has a commented warning in the code as follows...
#!/usr/bin/env python3
"""
Remote python server.
Execute Python commands remotely and send output back.
WARNING: This version has a gaping security hole -- it accepts requests
from any host on the internet!
"""
Why is this included in the standard install of python? Is it a concern?
Going to delete this file. If it's this dangerous it shouldn't even be here.
Related
I have developed a Python web server using Flask, and some of the endpoints make use of the subprocess module to call different executables. On development, using the Flask debug server, everything works fine. However, when running the server along with nginx+WSGI (on the exact same machine), some subprocess calls fail.
For example, one of the tools I'm using is Microsoft's dotnet, which I installed from my user as sudo apt-get install -y aspnetcore-runtime-5.0 and is then called from Python with the subprocess module. When I run the server with python3 server.py, it works like a charm. However, when using nginx and WSGI, the subprocess call fails with an exception that says: /bin/sh: 1: dotnet: not found.
I suspect this is due to the command not being accessible to the user and group running the server. I have used this guide as a reference to deploy the app, and on the wsgi .ini file, I have set uid = javierd and gid = www-data, while on the systemd .service file I have User=javierd, Group=www-data.
I have tried to add the executables' paths to /etc/profile, but it didn't work, and I don't know any other way to fix it. I find also very surprising that this happens to some executables, but not to all, and that it happes to dotnet, for example, which is located at /usr/bin/dotnet and therefore should be accessible to every user. Any idea on how to solve this problem? Furthermore, if somebody could explain me why this is happening, I would really appreciate the effort.
Thanks a lot!
Ok, finally after having a big headache, I noticed the error, and it was really simple.
On the tutorial I linked, when creating the system service file, the following line was included: Environment="PATH=/home/myuser/myfolder/enviroment/bin".
Of course, as this was overriding the path, there was no way of executing the commands. Once I notices it I just removed that line, restarted the service, and it was fixed.
I'm in the strange position of being both the developer of a python utility for our project, and the tester of it.
The app is ready and now I want to write a couple of blackbox tests that connect to the server where it resides (the server itself is the product that we commercialize), and launch the python application.
The python app allows a minimal command line scripting (some parameters automatically launch functions that otherwise would require user interaction at the main menu). For the residual user interactions, I usually try bash syntax like this:
./app -f <<< $'parameter1\nparameter2\n\n'
And finally I redirect everything to >/dev/null.
If I do manual checks at the command line on the server (where I connect via SSH), everything works smoothly. The app launch lasts 30 seconds, and after 30 seconds I'm correctly returned to the prompt.
Now to the blackbox testing part. Here I'm also using python (Py.test framework), but the test code resides on another machine.
The test runner machine will connect to the Server under test via Paramiko libraries. I've already used this a lot in scripting other functionalities of the product, and it works quite well.
But the problem in this case is that the app under test that I wrote in python uses the NCurses library in its normal behaviour ("import curses"), and apparently when trying to launch this in the Py.test script:
import paramiko
...
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.load_system_host_keys()
client.connect(myhost, myuser, mypass, mytimeout)
client.exec_command("./app -f <<< $'parameter1\nparameter2\n\n' >/dev/null")
Regardless the redirection to /dev/null, the .exec_command() prints this to standard error out with a message about the curses initialization:
...
File "/my/path/to/app", line xxx, in curses_screen
scr = curses.initscr()
...
_curses.error: setupterm: could not find terminal
and finally the py.test script fails because the app execution crashed.
Is there some conflicts between curses (used by the app under test) and paramiko (used by the test script)? As I said, if I connect manually via SSH to the server where the app resides and launch the command line manually with the silent redirection to /dev/null, it works as I would expect.
ncurses really would like to do input/output to a terminal. /dev/null is not a terminal, and some terminal I/O mode changes will fail in that case. Occasionally someone connects the I/O to a socket, and ncurses will (usually) work in that situation.
In your environment, besides the lack of a terminal, it is possible that TERM is unset. That will make setupterm fail.
Setupterm could not find terminal, in Python program using curses
wrong error from curses.wrapper if curses initialization fails
Some of my Python shell scripts are newly throwing security errors under Apple OSX 10.11, El Capitan. It seems the new App Transport Security doesn't like how the scripts are calling HTTP resources in plain text, rather than using HTTPS.
Fetching http://blahblah.com
Python[5553:5648168] App Transport Security has blocked a cleartext HTTP (http://)
resource load since it is insecure. Temporary exceptions can be configured
via your app's Info.plist file.
How might I go about fixing this? There is no HTTPS resource I can call, so I'm stuck with HTTP. The advice from Apple is to make an exception in the app's info.plist file, but this is a Python script invoked from a shell script, so there is no info.plist file to be edited.
Ideas? The root problem seems to be with webkit2png, which is in Python. Its non-HTTPS requests are being blocked by ATS, and there is no info.plist to modify.
I found a solution here that worked for me: https://apple.stackexchange.com/questions/210588/how-does-one-configure-a-temporary-exception-to-ats-on-el-capitan-and-fix-webkit
First make sure you have a version of webkit2png that is new enough to have the --ignore-ssl-check option. Version 0.5 does NOT have this option.
Second, you need to edit the source file and add a couple lines of code as shown here: https://github.com/bendalton/webkit2png/commit/9a96ac8977c386a84edb674ca1518e90452cee88
Finally use option as indicated in the solution linked above (copied here for convenience):
webkit2png --ignore-ssl-check [options] [http://example/]
Thanks for Arthur Hebert
At first I'm confused for the code then I figure it out
so I summarise the steps as follows for reference
import AppKit
Add the following code in your py script
AppKit.NSBundle.mainBundle().infoDictionary()['NSAppTransportSecurity'] = dict(NSAllowsArbitraryLoads = True)
Assume you are sure to use no HTTPS resource in MAC OSX higher than 10.11
The installation of webkit2png is not necessary in my case
i have running a python webserver by using this simple script -
from http.server import SimpleHTTPRequestHandler as RH
from socketserver import TCPServer
ServerName='localhost'
OnPort=8000
print ("Server is running at Port 8000")
TCPServer((ServerName, OnPort), RH).serve_forever()
it is running good and run my index.html file but it is not run .py file in browser when i type --
http://localhost:8000/myfile.py
it just show my python codes as it is i write in file ,it is not execute the code please help me to run my python file (.py) in browser by using this webserver only ,i don't want to use any framework or another webserver.
Is there any way to make a virtual host in this python server like apache.
if possible please suggest me that how to do this and any configuration file need to be configured or not.
thanx...
The problem is that SimpleHTTPRequestHandler only serves files out of a directory, it does not execute them. You must override the do_GET method if you want it to execute code.
You might want to check out CGIHTTPRequestHandler instead. I very briefly played with it on a linux based system and the CGI criteria was for a file to be executable and have the correct shabang. I'm not sure if this would work on Windows though ( if that is even a relevant concern )
With your example code you would only need to change RH to
import CGIHTTPServer.CGIHTTPRequestHandler as RH
Alternatively the 3rd party library Twisted has a concept of .rpy files that are mostly plain Python logic. http://twistedmatrix.com/trac/wiki/TwistedWeb
Note:
Just verified that the CGIHTTPRequestHandler works. Caveats is that all python files must be in a cgi-bin subdir, they must have a valid shabang, must be executable, and must provide valid CGI output.
Personally having written C++ CGI scripts in the 90's, the CGI route seems like the path to maddness... so check out Twisted, CherryPy, or Django ( those three mostly cover the Python web spectrum of possibilities )
Hello a client of mine bought a pretty bad web host and i don't even have ssh access, their ticket suport only answered with "yes we support python in our servers" but i can't run any .cgi .py or application.wsgi files. is there a sure way to tell if the server supports python?
I only have access to the ftp and the directadmin interface, i would like to know more before i can complaing again to their support system otherwise they will not pay attention.
The host is neubox.net this is what i already tried.
This tutorial http://www.howtoforge.com/embedding-python-in-apache2-with-mod_python-debian-etch worked on my dev machine, it says that i need to add a webhost in the apache2 /available-sites dir but obviously i don't have access to that folder in the hosting.
I also tried putting this script on the root of my host, called application.wsgi it didnt work
import os
import sys
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
I also tried this file application.py on the root
#!/usr/bin/env python
# -*- coding: UTF-8 -*-
# enable debugging
import cgitb
cgitb.enable()
print "Content-Type: text/plain;charset=utf-8"
print
print "Hello World!"
Those files were shown as plain text, i tried that exact same code but named application.cgi and oddly enough it returned a 404 error, the file of course its there.
I saw at the directadmin interface in site summary that
CGI-Bin OFF
So i guess thats the reason for the 404.
In the same page i see that the name servers are
http://ns115.neubox.net/
http://ns116.neubox.net
The first one says
Apache is functioning normally
This is their services comparison site (spanish) http://neubox.net/comparativo-hosting.php
I wish i could know what OS are they running i'm almost sure is linux because on my root there is a folder .htpasswd and those .folders are linux for hidden, but i'm not sure if thats a sure way to tell.
They gave me this url http://72.249.55.33/info.php its for phpinfo() i see fast-cgi but all the tuts about it talk about doing things like changing Apache configuration wich i obviously can't do, this is the end of my search right? they do not support python.
In your server thay sais that they have php, so maybe you can use this php function. to retrive more info, executing a python script:
# hacking.py
import sys
print sys.version_info
and after you make something like this
<?php
// echo $path = exec('pwd');
// exec python script
echo exec('python hacking.py');
?>
dont forget the file permissions
sacabuche has the correct answer. That script is a very simple way to test for Python support. It works on pretty much every flavor of linux and Berkely UNIX (BSD), a version of which is underlying OSX on a Mac Pro. If that script is not working for you, chances are it's a permissions issue.
I would continue working through the support staff on the host to get this resolved. If they can't help, you've got the wrong host. I've changed hosts several time due to lack of support, or misrepresented features, such as separate folder hierarchies per domain... something that's getting increasingly hard to find.
Currently I am on MochaHost, which I do recommend, since they seem to have it all together so far.
-Jack