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