I do not have python-3.8 installed and this would be the only pkg needing it.
Not sure but I don't think Gentoo is ready for python-3.8 only yet?

$ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pychroot import Chroot
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/dist-packages/pychroot/__init__.py", line 6, in <module>
    from .base import Chroot
  File "/usr/local/lib/python3.7/dist-packages/pychroot/base.py", line 42
    def __init__(self, path, /, *, log=None, mountpoints=(), hostname=None, skip_chdir=False):
                             ^
SyntaxError: invalid syntax
>>> from pychroot import Chroot
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/dist-packages/pychroot/__init__.py", line 6, in <module>
    from .base import Chroot
  File "/usr/local/lib/python3.7/dist-packages/pychroot/base.py", line 42
    def __init__(self, path, /, *, log=None, mountpoints=(), hostname=None, skip_chdir=False):

The same is working fine with 0.10.3

This could do useful things by mapping files to overlay onto the chroot image. For example, there could be distro-specific plugins that could query the host systems pkgs and thereby overlay pkgs onto the chroot.

This could probably also help isolate multiple sessions running against the same chroot location at once. For example, now if a directory or file needs to be created in order to perform bind mounts for one chroot, another chroot using the same chroot path and running simultaneously will see the created directory or file (but obviously not the contents since its in a different mount namespace).

Instead of maintaining a static list we should parse supported nodev fs types from /proc/filesystems since that will change from host to host.

Running pychroot from within a chroot fails with the following:

 # pychroot nvros-base
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/snakeoil/contexts.py", line 84, in __enter__
    self.child_setup()
  File "/usr/lib64/python2.7/site-packages/pychroot/base.py", line 101, in child_setup
    simple_unshare(pid=True, hostname=self.hostname, **kwargs)
  File "/usr/lib64/python2.7/site-packages/snakeoil/process/namespaces.py", line 332, in simple_unshare
    _mount(None, '/', None, MS_REC | MS_SLAVE)
  File "/usr/lib64/python2.7/site-packages/snakeoil/osutils/__init__.py", line 105, in _wrapper
    return f(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/snakeoil/osutils/mount.py", line 55, in mount
    raise OSError(e, os.strerror(e))
OSError: [Errno 22] Invalid argument

On further testing, it has the same problem if the outer chroot is a pychroot. If this can't be made to work, it would be nice if it at least failed with a sensible error message.

# pip install pychroot
Downloading/unpacking pychroot
  Downloading pychroot-0.9.12.tar.gz
  Running setup.py (path:/tmp/pip-build-EWhYFw/pychroot/setup.py) egg_info for package pychroot
    Traceback (most recent call last):
      File "<string>", line 17, in <module>
      File "/tmp/pip-build-EWhYFw/pychroot/setup.py", line 11, in <module>
        from snakeoil.dist import distutils_extensions as pkgdist
    ImportError: No module named snakeoil.dist
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "<string>", line 17, in <module>

  File "/tmp/pip-build-EWhYFw/pychroot/setup.py", line 11, in <module>

    from snakeoil.dist import distutils_extensions as pkgdist

ImportError: No module named snakeoil.dist

This is on Debian jessie.

It could be nice to use the semi-automatic generation method used by pkgcore, but that's a little too implementation specific right now.

Probably use sphinx and rst files to add some initial docs.

If you run something like
pychroot /path/to/chroot /bin/false

The return code comes back as a 0 instead of a 1. Logically pychroot should pass through the return code of the program it executes so that errors can be easily detected.

Requiring a switch to enable this so as to maintain compatibility with existing code would be acceptable.

Some native python lib like pyroute2 should probably get us most of the way there in terms of support for setting up loopback and virtual interfaces as well as providing basic routing/bridging back to the host.

so i'm calling pychroot in a function, and i have a bunch of custom bind mounts (and don't want to use the defaults, as it doesn't allow for e.g. Arch's pacman, which requires the chroot to be bind mounted as /)...

...
def myChroot(chrootdir, chroot_hostname, cmd):
    mountpoints = psutil.disk_partitions(all = True)
    mounts = []
    for m in mountpoints:
        mounts.append(m.mountpoint)
    cmnts = {}
    # see https://bugs.archlinux.org/task/46169
    if chrootdir not in mounts:
        cmnts[chrootdir + ':/'] = {'recursive': False, 'readonly': False, 'create': False}
    if (chrootdir + '/proc') not in mounts:
        cmnts['proc:/proc'] = {'recursive': True, 'create': True}
    if (chrootdir + '/sys') not in mounts:
        cmnts['/sys'] = {'recursive': True, 'create': True}
    if (chrootdir + '/dev') not in mounts:
        cmnts['/dev'] = {'recursive': True, 'create': True}
    if '/sys/firmware/efi/efivars' in mounts:
        if (chrootdir + '/sys/firmware/efi/efivars') not in mounts:
            cmnts['/sys/firmware/efi/efivars'] = {'recursive': True}
    if '/run' in mounts:
        if (chrootdir + '/run') not in mounts:
            cmnts['/run'] = {'recursive': True}

    pychroot.base.Chroot.default_mounts = {}
    chrootcmd = pychroot.base.Chroot(chrootdir, mountpoints = cmnts, hostname = chroot_hostname)
    chrootcmd.mount()
    with chrootcmd:
        import os
        os.system(cmd)
    chrootcmd.cleanup()

so all well and good. the mounts create and the chrooted command executes. HOWEVER, the mounts created don't unmount after execution, not even with the chrootcmd.cleanup().

With the following, however:

import pychroot
chroot = pychroot.Chroot('/var/tmp/chroottest')
with chroot:
    import os
    os.system('ls /home')

It does indeed unmount the mounted dirs.
(I should note that it also backgrounds on the command completion, which seems odd to me, but only from the python shell.)

am i doing something wrong or is this a bug? the documentation is admittedly a bit sparse, so apologies if i'm going about this the wrong way.

Arch Linux x86_64, fully up to date.
python 3.5
pychroot 0.9.16
snakeoil 0.7.1

It would also be good to officially document what fields the mountpoints argument supports as well.

So pychroot and Chroot can be run as non-root.

When rebuilding above in current gentoo I get:
`
running install_man
copying /var/tmp/portage/dev-python/pychroot-9999/work/pychroot-9999/build/sphinx/man/pychroot.1 -> /usr/share/man/man1

• ACCESS DENIED: open_wr: /usr/share/man/man1/pychroot.1
  error: could not create '/usr/share/man/man1/pychroot.1': Permission denied
• ERROR: dev-python/pychroot-9999::gentoo failed (install phase):
• (no error message)
• Call stack:

• ebuild.sh, line  124:  Called src_install
  

• environment, line 3230: Called distutils-r1_src_install
• environment, line 1078: Called _distutils-r1_run_common_phase 'python_install_all'
• environment, line 334: Called multibuild_foreach_variant 'distutils-r1_run_phase' 'python_install_all'
• environment, line 2129: Called _multibuild_run 'distutils-r1_run_phase' 'python_install_all'
• environment, line 2127: Called distutils-r1_run_phase 'python_install_all'
• environment, line 1042: Called python_install_all
• environment, line 2927: Called distutils-r1_python_install 'install_man'
• environment, line 954: Called esetup.py 'install' '--root=/var/tmp/portage/dev-python/pychroot-9999/image/_python3.6' 'install_man'
• environment, line 1310: Called die
• The specific snippet of code:

•   "${@}" || die "${die_args[@]}";
  

• If you need support, post the output of emerge --info '=dev-python/pychroot-9999::gentoo',
• the complete build log and the output of emerge -pqv '=dev-python/pychroot-9999::gentoo'.
• The complete build log is located at '/var/tmp/portage/dev-python/pychroot-9999/temp/build.log'.
• The ebuild environment file is located at '/var/tmp/portage/dev-python/pychroot-9999/temp/environment'.
• Working directory: '/var/tmp/portage/dev-python/pychroot-9999/work/pychroot-9999'
• S: '/var/tmp/portage/dev-python/pychroot-9999/work/pychroot-9999'
• --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
• LOG FILE: "/tmp/sandbox-4.log"

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: open_wr
S: deny
P: /usr/share/man/man1/pychroot.1
A: /usr/share/man/man1/pychroot.1
R: /usr/share/man/man1/pychroot.1
C: python3.6 setup.py install --root=/var/tmp/portage/dev-python/pychroot-9999/image/_python3.6 install_man

Noting that 0.9.18 was back in 2017 now, and quite a few changes have been made to bring things up-to-date in the master repo.

Hi!

It seems that master is no longer using test_requires but release 0.10.2 still is and snakeoil 0.8.9 doesn't have that any more, 0.8.8 was the last release to have it. So I think a new release 0.10.3 off master would help. Thanks in advance!

Best, Sebastian

PS: Origin is https://bugs.gentoo.org/758692

In python3.8 and newest snakeoil (0.7.1), setup.py fails to build:

[bts@cylon pychroot-0.10.1]$ python3 setup.py build
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    from snakeoil.dist import distutils_extensions as pkgdist
ImportError: cannot import name 'distutils_extensions' from 'snakeoil.dist' (/usr/lib/python3.8/site-packages/snakeoil/dist/__init__.py)

It's a handy replacement for hacked up shell scripts that set up namespacing and similar functionality for chroots. It would probably be installed as /usr/bin/pychroot.

Further customization could involve using config files for specifying various profiles that could alter properties such as different bind mounts to perform.

Might have to update/rewrite the byteplay module to support py3 in order to do this properly or figure out how to shim out own basic support for only what we need to step through the context code while grabbing instructions that add/modify the local namespace.

It could help simplify long custom bind mount lists that are used multiple for various chroots instead of having to rely on shell history. It would probably be easiest to do this an option to the script.

I'm trying this basic example:

from pychroot import Chroot
with Chroot("/home/yves/mock/lib/mageia-cauldron-x86_64/root"):
    pass

But I get:

Running script: "petit_test.py"
Traceback (most recent call last):
  File "petit_test.py", line 2, in <module>
    with Chroot("/home/yves/mock/lib/mageia-cauldron-x86_64/root"):
  File "/usr/lib/python3.10/site-packages/snakeoil/contexts.py", line 165, in __exit__
    raise exc
AttributeError: 'FileWrapper' object has no attribute 'fileno'

Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.8/pychroot", line 4, in <module>
    scripts.run(basename(__file__))
  File "/usr/lib/python3.8/site-packages/pychroot/scripts/__init__.py", line 32, in run
    sys.exit(tool())
  File "/usr/lib/python3.8/site-packages/snakeoil/cli/tool.py", line 79, in __call__
    ret = self.main()
  File "/usr/lib/python3.8/site-packages/snakeoil/cli/tool.py", line 185, in main
    self.handle_exec_exception(e)
  File "/usr/lib/python3.8/site-packages/snakeoil/cli/tool.py", line 170, in main
    exitstatus = func(self.options, self.out, self.err)
  File "/usr/lib/python3.8/site-packages/pychroot/scripts/pychroot.py", line 136, in main
    return c.exit_status
UnboundLocalError: local variable 'c' referenced before assignment

This happens on systemd and openrc systems, and at least on Ubuntu AND Gentoo.

I have had to "fix it" by doing this to the pychroot.py file:

@argparser.bind_main_func
def main(options, out, err):
    try:
        with Chroot(options.path, mountpoints=options.mountpoints,
                    hostname=options.hostname, skip_chdir=options.skip_chdir) as c:
            subprocess.run(options.command)
        return c.exit_status
    except FileNotFoundError as e:
        cmd = options.command[0]
        argparser.error(f'failed to run command {cmd!r}: {e}', status=1)
    except ChrootError as e:
        argparser.error(str(e), status=1)

I cannot remember initially if I had done it like that or directly below subprocess.run.

Hi I am currently trying to use your module to bootstrap distributions. I am using a Popen wrapper to run the commands in the chroot. The command run successfully but the never exit the chroot.

Environment : Python 3.8.7 | Kernel 5.9.12 | Gentoo

Popen wrapper :

def run(cmd):
    ''' subprocess.Popen wrapper '''
    process = Popen(cmd, universal_newlines=True,
        shell=True, stdout=PIPE,stderr=STDOUT)
    while True:
        output = process.stdout.readline()
        if output == '' and process.poll() is not None:
            break
        if output:
            print(output.strip())
    rc = process.poll()
    return rc

Chroot :

        chroot = Chroot(self.distro_dir)
        with chroot:
            print("Chrooting in {}".format(self.distro_dir))
            for cmd in self.script:
                run(cmd)
            print("Chroot process done !")

We should leave a notice in the README about Debian hardening regarding userns.

To enable, we need to:

echo 1 > /proc/sys/kernel/unprivileged_userns_clone

and make it persistant using:

echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/userns.conf

I'm also reading a similar path is available for newer kernel with a different switch.

For example, currently if a directory has to be created for a bind mount and then the process is sent a signal such as TERM or INT, we don't currently clean up the directory on exit.

Using Gentoo Linux, pychroot version 0.10.1, snakeoil version 0.8.8

Ever since migrating to Python 3 the pychroot command line utility hangs on exit and ignores all attempts to terminate it except SIGKILL

Happens with the system package, installing via pip, and installing in a virtualenv.
0.9.18 running under Python 2 works fine.

Tried running under PDB. Hangs as soon as the shell is exited.

I haven't finished setting up to run it under GDB yet, but can do that if you think it will help.

Searching the web, the closest I find is other projects having trouble with sys.exit hanging under certain circumstances with Python 3. That seems like it could be a possibility here, but I don't have any solid evidence to that effect.

I tried to run pychroot 0.10.4 inside a context manager that mounts and umounts a filesystem using subprocess.run, and the result is odd: the unmount call fails because the filesystem is busy, and the context ending method is called multiple times. The same thing happens when calling pychroot inside an equivalent try/finally block.

My initial attempt was on a filesystem containing a valid OS tree, but this simpler example illustrates what's happening:

print("mount")
subprocess.run(["/bin/mount", "-ttmpfs", "none", "/mnt"])

try:
    with contextlib.suppress(SystemExit), pychroot.Chroot("/mnt"):
        pass
finally:
    print("finally umount")
    subprocess.run(["/bin/umount", "/mnt"])

The snippet above returns:

mount
finally umount
umount: /mnt: target is busy.
finally umount
Traceback (most recent call last):
  File "./w2.py", line 16, in <module>
    subprocess.run(["/bin/umount", "/mnt"])
  File "/usr/lib/python3.8/subprocess.py", line 489, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1637, in _execute_child
    self.pid = _posixsubprocess.fork_exec(
OSError: [Errno 12] Cannot allocate memory
finally umount

Note that the finally block runs three times and actually works in the third attempt, but the result is very ugly. Is that a known problem or expected behavior when using pychroot? Any advice on how to handle this situation?

Hi,

I am trying to run some code using pychroot.
Even if i add mountpoints, trying to run anything using subprocess.run() end with an error:
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/python3.6': '/usr/bin/python3.6'
(here's an example with python).
os.system() from the other hand always returns 32512.
Am i missing something? Or am i not allowed to use them inside pychroot?

Regards

I am expecting my script to reach a conclusion and then exit() but it just hangs and needs to be killed.

with Chroot('/srv/chroot/ubuntu-1604'):
proc = subprocess.Popen('apt-get install -y curl', shell=True, stdin=None, stdout=open(os.devnull,"wb"), stderr=STDOUT, executable="/bin/bash")
proc.wait()
.....
sys.exit()

I thought it might be something I am doing wrong so I just called it from the cmd line and I get this:
sudo pychroot /srv/chroot/ubuntu-1604/ lsb_release -a

I have to kill this one as well. Any idea what is going on?

Hi!

The docs advertise a command

sudo pychroot -B /home/user1 ~/chroot

but it seems that -B is not (or no longer?) supported:

# pychroot -B /home/user1 ~/chroot
usage: pychroot [-h] path [command [command ...]]
pychroot: error: unrecognized arguments: -B

# pychroot --help
usage: pychroot [-h] path [command [command ...]]

A simple chroot(1) workalike

positional arguments:
  path        path to newroot
  command     optional command to run

optional arguments:
  -h, --help  show this help message and exit

Am I missing something?

I'm running version 0.9.9 on Gentoo.

A chroot I was previously able to chroot into just turned unenterable.
(The connection died and since there was no tmux open to re-enter, I killed pychroot's offspring processes.)

Now entering fails like this:

# pychroot wheezy_chroot/ /bin/bash 
[Errno 2] No such file or directory

# ls -l wheezy_chroot/bin/bash
-rwxr-xr-x 1 root root 975488 Sep 25  2014 wheezy_chroot/bin/bash

It turns out the problem is actually piles of letfover mounts from previous runs. To give an excerpt of findmnt output:

├─/root/wheezy_chroot/dev                     udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ ├─/root/wheezy_chroot/dev/pts               devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/root/wheezy_chroot/dev/shm               tmpfs      tmpfs      rw,nosuid,nodev
│ ├─/root/wheezy_chroot/dev                   udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ ├─/root/wheezy_chroot/dev/pts             devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ ├─/root/wheezy_chroot/dev/shm             tmpfs      tmpfs      rw,nosuid,nodev
│ │ ├─/root/wheezy_chroot/dev                 udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ ├─/root/wheezy_chroot/dev/pts           devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ ├─/root/wheezy_chroot/dev/shm           tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ ├─/root/wheezy_chroot/dev               udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ ├─/root/wheezy_chroot/dev/pts         devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ ├─/root/wheezy_chroot/dev/shm         tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ ├─/root/wheezy_chroot/dev             udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ │ ├─/root/wheezy_chroot/dev/pts       devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ │ ├─/root/wheezy_chroot/dev/shm       tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ │ ├─/root/wheezy_chroot/dev           udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ │ │ ├─/root/wheezy_chroot/dev/pts     devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ │ │ ├─/root/wheezy_chroot/dev/shm     tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ │ │ ├─/root/wheezy_chroot/dev         udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755
│ │ │ │ │ │ │ ├─/root/wheezy_chroot/dev/pts   devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ │ │ │ │ │ │ ├─/root/wheezy_chroot/dev/shm   tmpfs      tmpfs      rw,nosuid,nodev
│ │ │ │ │ │ │ └─/root/wheezy_chroot/dev       udev       devtmpfs   rw,relatime,size=10240k,nr_inodes=2036335,mode=755

This is on Debian wheezy btw. I didn't do any mounting inside or outside the chroot otherwise, myself.

One such pattern is something like the following:

localhost $ sudo pychroot -R /home/user1 --ro $SSH_AUTH_SOCK --ro /etc/passwd --ro /etc/shadow ~/chroot /bin/bash
localhost@chroot # su user1
localhost@chroot $ ssh some_host
remotehost $ exit
localhost@chroot $ exit
localhost@chroot # exit
... hangs ...

Sending SIGINT doesn't do anything either when it's hung so that should be fixed too.