On 1/9/12 16:41 , Philipp Hagemeister wrote:
I want to forbid my application to access the filesystem. The easiest
way seems to be chrooting and droping privileges. However, surprisingly,
python loads the codecs from the filesystem on-demand, which makes my
program crash:
import os
os.getuid()
0
os.chroot('/tmp')
''.decode('raw-unicode-escape')
Traceback (most recent call last):
File "<stdin>", line 1, in<module>
(Interestingly, Python goes looking for the literal file "<stdin>" in
sys.path. Wonder what happens if I touch
/usr/lib/python2.7/dist-packages/<stdin>).
Is there a neat way to solve this problem, i.e. have access to all
codecs in a chroot?
The traditional solution is to copy the data you want to make available
into the subdirectory tree that will be used as the target of the chroot.
If not, I'd love to have a function codecs.preload_all() that does what
my workaround does:
import codecs,glob,os.path
encs = [os.path.splitext(os.path.basename(f))[0]
for f in glob.glob('/usr/lib/python*/encodings/*.py')]
for e in encs:
try:
codecs.lookup(e)
except LookupError:
pass # __init__.py or something
enumerate /usr/lib/python.*/encodings/*.py and call codecs.lookup for
every os.path.splitext(os.path.basename(filename))[0]
Dou you see any problem with this design?
Only the timing. If you're using the shell level chroot(1) program then
you're already chroot'd before this can execute. If you're using
os.chroot, then:
a) you're unix specific
b) your program must initially run as root
c) you have to drop privilege yourself rather than letting something
like chroot(1) handle it.
As alternatives, you might consider building a root file system in a
file and mounting it separately on a read-only basis. You can chroot
into that without much worry of how it will affect your regular file system.
With btrfs as root, you can create snapshots and chroot into those. You
can even mount them separately, read-only if you like, before chrooting.
The advantage of this approach is that the chroot target is built
"automatically" in the sense that it's a direct clone of your underlying
root file system, without allowing anything in the underlying root file
system to be altered. Files can be changed, but since btrfs is
copy-on-write, only the files in the snapshot will be changed.
--rich
--
http://mail.python.org/mailman/listinfo/python-list