Is Python really a scripting language?
Eric S. Johansson
esj at harvee.org
Sat Dec 15 09:23:35 EST 2007
John Nagle wrote:
> Yes. One of the basic design flaws of UNIX was that interprocess
> communication was originally almost nonexistent, and it's still not all that
> great. It's easy to run other programs, and easy to send command line
> parameters, but all you get back is a status code, plus console-type output.
>
> The UNIX world might have been quite different if, when you ran a
> subprocess, at the end you got return values for the command line
> parameters (argv/argc) and the environment back. Then programs
> would behave more like big subroutines. But all you get back
> is a status code, so running programs from a "script" tends to be
> a somewhat "blind" one-way process.
not if you use pickle. the example below is not complete and I need to fix it
to not raise privileges if name is None but it is complete enough to give you an
idea. the parent uses spawn_sub to send data to/from child. child uses
read_input/write_output to move data from/to the parent. I should convert it to
something like json to make it possible to work with other languages.
class process_handler (object):
def read_input (self):
"""get the input from standard and can convert to Python
object"""
pickle_input = sys.stdin.read()
real_object = pickle.loads(pickle_input)
return real_object
def write_output (self, real_object, err_object = None):
""" errors to standard error, output to standard out, objects
in pickled form"""
pickled_error = pickle.dumps(err_object)
sys.stderr.write(pickled_error)
pickled_output = pickle.dumps(real_object)
sys.stdout.write(pickled_output)
def spawn_sub(self, cmd_list,stuff_in, run_as=None):
"""command_list is just that, a list of the command and all of its
arguments.
stuff_in is the string sent to the sub process via standard in
stuff_out is the string returned from the sub process via standard out
error_stuff is the string returned from standard error.
stuff_out and error_stuff are returned as a tuple
run_as is the user name you want to run as. This uses a trick with
sudo to enable privilege escalation
this is an example of a bad escalation specification in
sudoers. It's sometimes bad because it doesn't restrict
who can use the command. If you are trying to run a
program as a common but different user (such as www-data
because you need to share a database with a Web server, the
badness is measured in terms of what data said program can
change or reveal. If the access cannot be exploited, then
they should be okay. Unfortunately, in almost every
circumstance where privilege escalation techniques are
useful, there is an exploit waiting to happen.
be careful.
ALL ALL = (www-data) NOPASSWD: /home/esj/vacation_scan.py
"""
# syslog.syslog("subprocess args %s"%str(cmd_list))
p = subprocess.Popen(cmd_list, shell=False, bufsize=4000,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
close_fds=True)
# always pickle what passes through even if it is a None
pickle_in = pickle.dumps(stuff_in)
(pickled_output, pickled_error) = p.communicate(pickle_in)
stuff_output = pickle.loads(pickled_output)
error_stuff = pickle.loads(pickled_error)
# syslog.syslog(" stuff_output %s, error_stuff %s"%( stuff_output,
error_stuff))
return (stuff_output, error_stuff)
--
Speech-recognition in use. It makes mistakes, I correct some.
More information about the Python-list
mailing list