Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #12740 > unrolled thread

Can't use subprocess.Popen() after os.chroot() - why?

Started byErik <erik.williamson@gmail.com>
First post2011-09-04 07:22 -0700
Last post2011-09-07 02:01 +0100
Articles 4 — 4 participants

Back to article view | Back to comp.lang.python


Contents

  Can't use subprocess.Popen() after os.chroot() - why? Erik <erik.williamson@gmail.com> - 2011-09-04 07:22 -0700
    Re: Can't use subprocess.Popen() after os.chroot() - why? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-09-04 17:25 +0200
      Re: Can't use subprocess.Popen() after os.chroot() - why? Hans Mulder <hansmu@xs4all.nl> - 2011-09-04 19:36 +0200
    Re: Can't use subprocess.Popen() after os.chroot() - why? Nobody <nobody@nowhere.com> - 2011-09-07 02:01 +0100

#12740 — Can't use subprocess.Popen() after os.chroot() - why?

FromErik <erik.williamson@gmail.com>
Date2011-09-04 07:22 -0700
SubjectCan't use subprocess.Popen() after os.chroot() - why?
Message-ID<b46caa73-f7a7-4154-8643-cf77b052d31e@glegroupsg2000goo.googlegroups.com>
Hi All,

I'm trying to do the following: 

import os
from subprocess import Popen, PIPE

os.chroot("/tmp/my_chroot")
p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
stdout_val, stderr_val = p.communicate()
print stdout_val

but the Popen call is dying with the following exception:

Traceback (most recent call last):
  File "./test.py", line 7, in <module>
    p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
  File "/home/erik/lib/python2.7/subprocess.py", line 679, in __init__
  File "/home/erik/lib/python2.7/subprocess.py", line 1224, in _execute_child
  File "/home/erik/lib/python2.7/pickle.py", line 1382, in loads
  File "/home/erik/lib/python2.7/pickle.py", line 858, in load
  File "/home/erik/lib/python2.7/pickle.py", line 971, in load_string
LookupError: unknown encoding: string-escape

Am I missing something here? does the chroot environment need to be populated with more than just the date executable in this case? I can't seem to find any examples of this & would appreciate any insight.  

Thanks,
Erik.

[toc] | [next] | [standalone]


#12741

FromAlain Ketterlin <alain@dpt-info.u-strasbg.fr>
Date2011-09-04 17:25 +0200
Message-ID<87zkikz5vn.fsf@dpt-info.u-strasbg.fr>
In reply to#12740
Erik <erik.williamson@gmail.com> writes:

> import os
> from subprocess import Popen, PIPE
>
> os.chroot("/tmp/my_chroot")
> p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
> stdout_val, stderr_val = p.communicate()
> print stdout_val
>
> but the Popen call is dying with the following exception:
>
> Traceback (most recent call last):
>   File "./test.py", line 7, in <module>
>     p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
>   File "/home/erik/lib/python2.7/subprocess.py", line 679, in __init__
>   File "/home/erik/lib/python2.7/subprocess.py", line 1224, in _execute_child
>   File "/home/erik/lib/python2.7/pickle.py", line 1382, in loads
>   File "/home/erik/lib/python2.7/pickle.py", line 858, in load
>   File "/home/erik/lib/python2.7/pickle.py", line 971, in load_string
> LookupError: unknown encoding: string-escape
>
> Am I missing something here? does the chroot environment need to be
> populated with more than just the date executable in this case?

Yes, because /bin/date is probably dynamically linked: you need the libs
as well. (Try first with a statically linked executable, e.g.,
/bin/busybox, and everything should be ok).

I agree the message is strange. For some reason, subprocess is calling
pickle.loads, which calls rep.decode("string-escape"), which probably
needs to access some file and fails because of the chroot().

I woud advise to use the chroot command instead of chrooting your python
process, if that's possible for you.

-- Alain.

[toc] | [prev] | [next] | [standalone]


#12744

FromHans Mulder <hansmu@xs4all.nl>
Date2011-09-04 19:36 +0200
Message-ID<4e63b71c$0$2421$e4fe514c@news2.news.xs4all.nl>
In reply to#12741
On 4/09/11 17:25:48, Alain Ketterlin wrote:
> Erik<erik.williamson@gmail.com>  writes:
>
>> import os
>> from subprocess import Popen, PIPE
>>
>> os.chroot("/tmp/my_chroot")
>> p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
>> stdout_val, stderr_val = p.communicate()
>> print stdout_val
>>
>> but the Popen call is dying with the following exception:
>>
>> Traceback (most recent call last):
>>    File "./test.py", line 7, in<module>
>>      p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
>>    File "/home/erik/lib/python2.7/subprocess.py", line 679, in __init__
>>    File "/home/erik/lib/python2.7/subprocess.py", line 1224, in _execute_child
>>    File "/home/erik/lib/python2.7/pickle.py", line 1382, in loads
>>    File "/home/erik/lib/python2.7/pickle.py", line 858, in load
>>    File "/home/erik/lib/python2.7/pickle.py", line 971, in load_string
>> LookupError: unknown encoding: string-escape
>>
>> Am I missing something here? does the chroot environment need to be
>> populated with more than just the date executable in this case?
>
> Yes, because /bin/date is probably dynamically linked: you need the libs
> as well. (Try first with a statically linked executable, e.g.,
> /bin/busybox, and everything should be ok).

/bin/date also needs timezone information from either /etc/localtime
or /usr/share/zoneinfo/ (depends on whether the environment variable
TZ is set).

It may need other data files as well (e.g. for localization).

> I agree the message is strange. For some reason, subprocess is calling
> pickle.loads, which calls rep.decode("string-escape"), which probably
> needs to access some file and fails because of the chroot().

The child process tries to exec /bin/date and fails.  The child process
then pickles the resulting exception and sends it to the parent via
a pipe that the parent has created for this purpose.  The parent then
tries to unpickle the exception and fails to find the string-escape
decoder in its usual place, due to the chroot.

If you fix that, then the parent process will be able to re-raise the
exception from the child process (which may or may not confuse you).

> I woud advise to use the chroot command instead of chrooting your python
> process, if that's possible for you.

You'll find you need to copy a lot of dynamic libraries and several
data files to your chroot box, before the normal commands in /bin work.

Keep in mind that the more features you copy to the chroot jail, the
easier it becomes to escape from it.

Hope this helps,

-- HansM

[toc] | [prev] | [next] | [standalone]


#12863

FromNobody <nobody@nowhere.com>
Date2011-09-07 02:01 +0100
Message-ID<pan.2011.09.07.01.01.11.196000@nowhere.com>
In reply to#12740
On Sun, 04 Sep 2011 07:22:07 -0700, Erik wrote:

> I'm trying to do the following: 

> os.chroot("/tmp/my_chroot")
> p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)

> but the Popen call is dying with the following exception:

> LookupError: unknown encoding: string-escape
> 
> Am I missing something here? does the chroot environment need to be
> populated with more than just the date executable in this case?

Yes. It also needs to include any parts of the Python run-time which
Python will try to load while executing subsequent code. In this case, the
module which implements the string-escape encoding.

But fixing that will probably show up yet more files which need to exist
within the pseudo-root. E.g. any shared libraries which the executable
needs (probably at least libc), and any data files which those libraries
need (in the case of /bin/date, it may need /etc/timezone; many programs
may require locale data if you aren't in the "C" locale, and so on).

Whether from Python or from C, chroot() requires a good understanding of
the low-level details of your operating system. If you don't know how to
build a minimal Linux distribution from scratch, you're going to have to
learn many of those details in order to use chroot().

For any non-trivial chroot() usage, it's often easier to install a small
newlib+busybox-based Linux distribution under the pseudo-root than to try
to re-use files from and existing (presumably glibc+coreutils-based)
desktop/server distribution.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web