proot-me/proot

chroot, mount --bind, and binfmt_misc without privilege/setup for Linux

proot's Issues

Clean debian

Hi,

I create a repository with all stuff needed to build debian package in a good way.
It only need #49 to work.

I can give you ownership if you want to. :)

I will also create launchpad project to autobuild packages on a ppa repository.
Can be far easier for any ubuntu user.

PRoot and Gentoo's sanbox do not mix well.

How to reproduce:

proot -R stage3-amd64-hardened+nomultilib-20140619 sandbox sh -c 'test -x "/usr/bin/objdump"; echo $?'

Current result: 1
Expected result: 0

GNU tar: "file changed as we read it"

Step to reproduce:

echo >1      # not touch, size must be >0
chmod -w 1   # must be read only
proot -0 tar -cf 1.tar 1
/bin/tar: 1: file changed as we read it

Notes:
This happens only on older versions of GNU tar (happns on 1.23 but not on 1.26). According to strace the newer version uses newfstatat() rather than stat().

epsxe: proot warning: process is doing suspicious brk()

• Host: Slackware-14.1/Linux-3.10.17/x86_64
• Guest: Ubuntu-13.04/x86
• Command: proot -R ubuntu-13.04-x86 epsxe
• Output:

  proot warning: process 4183 is doing suspicious brk()
  Running ePSXe emulator version 1.9.4. 
  [...]
  

Unable to run dynamic uClibc-linked binaries with proot.

Hello,

Whenever I enter via proot an uClibc chroot I am unable to run dynamicly linked binaries, even a hello world, if I do however compile it staticly, it does work.

Test chroot http://landley.net/aboriginal/downloads/binaries/root-filesystem/root-filesystem-x86_64.tar.bz2

% echo 'gcc foo.c; ./a.out' | proot -r rootfs_x86_64/ -w / sh
Standalone execution is not enabled

% echo 'gcc foo.c -static; ./a.out' | proot -r rootfs_x86_64/ -w / sh
Hello, world!

If I however enter the rootfs_x86_64 as root via chroot, I can execute the dynamic binary.

Add support for response files, ie "@file" options on the command-line.

Reference: #46 (comment)

Default verbosity of proot v2.2 causes unexpected output

With proot v2.2 I have too messages with the default options:

$ /proot /bin/ls /etc/profile
proot info: started
/etc/profile
proot info: exited

This causes troubles as the "proot info" messages make proot non transparent in non-warning and non-error cases.

proot modifying its argument

Reported by: Yann Droneaud
Ref: https://bugzilla.stlinux.com/show_bug.cgi?id=29185
Content:

Hi,

It seems proot is rewriting its arguments, so that the command line reported by
proc (ps, pstree, top) is slightly wrong:

sdk2.sh script run it with:

proot -b /var/lib/mock/fedora-17-i386-sdk2-test/root/opt/STM/STLinux-2.4:/opt/STM/STLinux-2.4 /bin/bash --noprofile --rcfile /home/ydroneaud/src/sdk2/pltf/stlinux/sdk2rc.sh

Then ps report:

proot -b /var/lib/mock/fedora-17-i386-sdk2-test/root/opt/STM/STLinux-2.4 /opt/STM/STLinux-2.4 /bin/bash --noprofile --rcfile /home/ydroneaud/

The -b argument got cut in two, removing the ":"

Using proot-v2.4.1-2 with Fedora 17 x86_64.

Regards.

Java cannot be executed if memory exceds 1 GB

In PRoot 3.2.2, if JVM is launched with 1 GB of memory, JVM hangs. It was observed when launching a Java application as follows:

[PRootShlell]$ -vmargs -Xmx512m -XX:MaxPermSize=512m

A CARE package can be provided if required.

argv0 not working correctly for certain PATHs

"Multicall" binaries (busybox, for example) are not being run correctly for certain PATHs.

For example, in a rootfs where /bin/sh is symlinked to busybox, running it under proot will not work correctly, unless PATH is set a certain way (I am not sure if the target (e.g. busybox) has to be, or if symlink (e.g. sh) has to be, or both need to be, in PATH).

Instead of starting a new process of sh, proot will freeze, not doing anything. Terminating using Ctrl-C will stop proot as usual, though.

Note: this can be worked around in cases where there is a way to choose what to run without changing argv0 (for example by running busybox sh)

Unexpected "permission denied" when using "proot -0"

Setup:

$ mkdir -p a/b
$ chmod -rwx a

Expected failure (without PRoot):

$ rm -fr a
rm: cannot remove 'a': Permission denied

Unexpected failure (with PRoot):

$ proot -0 rm -fr a
/bin/rm: cannot remove ?a/b?: Permission denied

Expected behavior:

$ proot -0 rm -fr a
$ echo $?
0
$ ls -ld a
/bin/ls: cannot access a: No such file or directory

Unable to build busybox with uClibc chroot within proot-ed env.

Hi,

I am testing whatever I can build full toolset using proot and apperantly I can't build busybox if I proot to uClibc env, but if I chroot to the same very env it does work.

HOSTCC  scripts/basic/fixdep 
Segmentation fault

Tested on busybox 1.21.1
The uClibc env I've tested it on https://bitbucket.org/piotrkarbowski/better-initramfs/downloads/aboriginal-r1649-with-ldso-rootfs-x86_64.tar.bz2

I do suspect it to be uClibc bug but I can't confirm it.

sysenter start/end trace inversion on brk/mmap syscalls

Hi,

Seems tracing in PRoot doesn't handle nested syscalls :

proot info: pid 7419: sysenter start: brk(0x0, 0x0, 0x0, 0xbfebfbff, 0x37f, 0x64) = 0xffffffffffffffda [0x7fffffffecc8, 0]
proot info: pid 7419: sysenter end: mmap(0x0, 0x801000, 0x3, 0x22, 0xffffffffffffffff, 0x0) = 0xffffffffffffffda [0x7fffffffecc8, 0]
proot info: pid 7419: sysexit start: mmap(0x0, 0x801000, 0x3, 0x22, 0xffffffffffffffff, 0x0) = 0x7ffff77fc000 [0x7fffffffecc8, 0]
proot info: pid 7419: sysexit end: brk(0x0, 0x0, 0x0, 0xbfebfbff, 0x37f, 0x64) = 0x7ffff77fd000 [0x7fffffffecc8, 0]

regards,
Nicolas

Do not seccomp-trace any syscalls when there are no bindings. This should improve performance of ATOS extensions a alot.

The new instance of QEMU executed on the behalf of the forked process tries to run gdbserver on the same port as its parent.

Details: https://groups.google.com/forum/?fromgroups#!topic/proot_me/ev2rS7kma30

proot -0 does not set AT_*ID ELF auxiliary vectors

Current behavior:

$ proot -0 env LD_SHOW_AUXV=1 true
[...]
AT_UID:          1000
AT_EUID:         1000
AT_GID:          100
AT_EGID:         100
[...]

Expected behavior:

$ sudo env LD_SHOW_AUXV=1 true
[...]
AT_UID:          0
AT_EUID:         0
AT_GID:          0
AT_EGID:         0
[...]

Add a mechanism to add new [fake] entries in /proc, for instance ``/proc/proot/config``.

CARE: Set AT_HWCAP ELF auxiliary vector to 0 to ensure better reproducibility

That way, both initial and reproduced executions use the same code (in the standard C library).

Today, this can be achieved by setting LD_HWCAP_MASK to 0 before starting CARE.

uname not fully hooked

Running "uname -a" under care gave different answers depending on the.

First execution on hostA:
$ care -o care-uname.tar uname -a
Linux hostA 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux

Re-execution on the same machine is identical while on another machine (hostB):
$ ./care-uname/re-execute.sh
Linux hostB 3.11-2-amd64 #1 SMP Wed Jul 9 15:46:26 EDT 2008 x86_64 GNU/Linux

However the kernel version hook is working correctly as hostB is not running v3.11-2.

No more compiled man in the tarball

Since 4.0.0 there is no more pre-compiled man page in the tarball so it adds a make depends for rst2xml.

Is it an oversight or is there some reason?

Regards,

Nicolas

samba4: error: the configuration failed

• Host: any
• Guest: any
• Command: proot -w samba-4.1.0 -0 ./configure
• Output:

  Checking whether setuidx is available : samba-4.1.0/source3/wscript:997: error: the configuration failed (see 'samba-4.1.0/bin/config.log')
  

Job control (stop/continue, a.k.a. suspend/resume) does not work

How to reproduce:

$ proot bash
$ emacs
^Z
[1]+  Stopped                 emacs

Expected behavior: emacs is stopped.

Actual behavior: emacs still runs.

wine configure script is failing under script

Hi,

With wine git master, ./configure is failing on debian testing with :

configure: creating ./config.status
../../src/configure: xrealloc: ../bash/subst.c:5188: cannot allocate
2097152 bytes (5230592 bytes allocated)
configure: error: write failure creating ./config.status

Problematic part of the configure file (see 1) :

cat Make.tmp - <<\_WINE_EOF >\$tmp/makefile && mv -f \$tmp/makefile \$1 && rm -f Make.tmp && return
`cat $wine_rules_file`
_WINE_EOF

$wine_rules_file is a relatively big file and it doesn't seems to like embedding it.

I have a trace with proot -v 9 if wanted ... I've filtered out the part associated with the failing process on 2.

Perhaps using MREMAP_MAYMOVE with mremap(2) could help ?

Nicolas.

Daemons aren't moved into the background correctly.

From issue #8:

As of my understanding, the issue with dtach under proot is due to the
fact that proot waits (for ptrace events) in the foreground, even if
all of its tracees were moved to the background. The problem is
reproducible with the code below: under proot, the terminal control is
never passed back to the parent shell, as it ought to be. In this
regard, proot is not transparent.

int main()
{
    daemon(0, 0);
    while (1)
        sleep(1);
    return 0;
}

Note: strace -f suffers the same issue.

proot contains RWX sections

When compiling proot 3.2.1 in Gentoo i have such warning:

• QA Notice: The following files contain writable and executable sections
• Files with such sections will not work properly (or at all!) on some
• architectures/operating systems. A bug should be filed at
• http://bugs.gentoo.org/ to make sure the issue is fixed.
• For more information, see http://hardened.gentoo.org/gnu-stack.xml
• Please include the following list of files in your report:
• Note: Bugs should be filed for the respective maintainers
• of the package in question and not [email protected].
• RWX --- --- usr/bin/proot

Gentoo bugreport: https://bugs.gentoo.org/show_bug.cgi?id=493416

Please clarify, is such sections are really needed in proot and if yes, what workarounds, suggested at[1] fits, thanks.

[1] - http://hardened.gentoo.org/gnu-stack.xml

add recursive bind option

I'd like to request a recursive bind option that works like this:

proot --recursive-bind /tmp/usr:/usr

Instead of hiding the whole /usr dir it should iterate over /tmp/usr/* and bind all the contained files.

I know the same thing could be implemented with a shellscript, but if there are a lot of files in /tmp/usr/* we could get a very long commandline and the shell may truncate it...

Error processing symlinks resolved through /proc/self

This works: sh -c 'echo test | cat /dev/stdin'

This doesn't: proot sh -c 'echo test | cat /dev/stdin'

ptrace emulation

Currently, it's not possible to execute GDB, strace, or any other program based on "ptrace" under PRoot since this latter is also based on this syscall and the Linux kernel allows only one ptracer per process. The solution is to emulate this syscall in PRoot.

Implicit binding to temporary location results in failure

With proot v2.2 I have a issue with a double binding to the same location causing errors.
As the implicit binding created by proot itself is choosen, I can't access the actual host location.
I have not seen the issue on previous proot versions.
Note that I have nested bindings, If I remove the three bindings and replace it by a single binding /work1/gcc-build:/opt/gcc-build, I am not able to reproduce the error anymore.

The issue can be reproduced with a very specific sequence:

• remove recursively the /rootfs/opt directory
• run once the test (see below) -> this time it works

• actually the /rootfs/opt have been created by proot after this run (but the directory /rootfs/opt/gcc-build was not created)

• run a second time the test --> now proot fails with the double binding

• looking at the rootfs proot has now created the /rootfs/opt/gcc-build dir

• run a third time the test -> it works again and forever.

The test is:

/work1$ /work1/guillon/gcc-build/devimage/bin/proot -b /work1/gcc-build:/opt/gcc-build -b /work1/gcc-build/build:/opt/gcc-build/build -b /work1/gcc-build/devimage:/opt/gcc-build/devimage -r /work1/guillon/gcc-build/distros/rhlinux-i586-5el-rootfs -w /opt/gcc-build/build /opt/gcc-build/test.sh

When it fails the following message is outputed:
proot warning: both '/work1/gcc-build' and '/tmp/proot-7886-XwThQF/opt/gcc-build' are bound to '/opt/gcc-build', only the last binding is active.
proot info: started
proot warning: execv("/opt/gcc-build/test.sh"): No such file or directory
proot info: possible causes:
* is a script but its interpreter (eg. /bin/sh) was not found;
* is an ELF but its interpreter (eg. ld-linux.so) was not found;
* is a foreign binary but no was specified;
* does not work correctly (if specified).
proot info: exited

Binding over symlinks breaks destination

Steps to reproduce

$ mkdir foo
$ touch foo/bar
$ ln -s /etc bla
$ proot -b foo:bla ls /etc/
  bar
$ tree .
 .
 ├── bla -> /etc
 └── foo
     └── bar

The same thing happen if the symlink points to a file.

proot warning: execve("/bin/true"): Operation not permitted

I get the following error when running proot v3.1 on Linux Mint 15 (based on Ubuntu 13.04) x86_64:

[penguin]src$ ./proot -v 1 true
proot info: binding = /
proot info: exe = /bin/true
proot info: command = true
proot info: initial cwd = /home/brettj/src/PRoot/src
proot info: verbose level = 1
proot info: pid 10727: access to "/dev/pts/1" (fd 0) won't be translated until closed
proot info: pid 10727: access to "/dev/pts/1" (fd 1) won't be translated until closed
proot info: pid 10727: access to "/dev/pts/1" (fd 2) won't be translated until closed
proot info: ptrace acceleration (seccomp mode 2) enabled
proot warning: execve("/bin/true"): Operation not permitted
proot info: possible causes:
  * <program> is a script but its interpreter (eg. /bin/sh) was not found;
  * <program> is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * <program> is a foreign binary but no <qemu> was specified;
  * <qemu> does not work correctly (if specified).
proot error: see `proot --help` or `man proot`.
proot info: pid 10728: exited with status 1
[penguin]src$ uname -a
Linux penguin 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Possibly this is could be reproduced on regular Ubuntu too... this is pretty-much a fresh install of Mint so it shouldn't be that difficult to reproduce the error in a VM.

I had a try with different proot versions and proot v2.4.1 works, but v3.0 and later doesn't. I notice that proot is using seccomp filter on my system, are there any potential side-effects there?

Add a way to get the reverse translation of a path

Something like that:

proot [bindings] -x /usr/local/bin

or maybe:

  proot [bindings] readlink /proc/proot/detranslate/usr/local/bin

Add an option to archive a path even if it is not used during the initial execution.

Details: http://linuxfr.org/news/care-et-la-reproductibilite-des-executions#comment-1517970

Add an option to force the output archive format

Details: https://linuxfr.org/nodes/101156/comments/1518591

CARE might produce archives that can't be extracted without DAC_OVERRIDE capability (eg. being "root")

How to reproduce this issue:

$ mkdir -p a/b; chmod a-rwx a
$ care -o test.cpio sh -c 'chmod +rx a; ls -l a'
[...]
$ cpio -idmuvF test.cpio
[...]
cpio: test/rootfs/tmp/test/a/b: Cannot mkdir: Permission denied
[...]

Workaround:

$ proot -0 cpio -idmuvF test.cpio

Possible solution: add to CARE an "extract" feature that does something similar to the workaround above.

Error when building Emacs

How to reproduce this error:

proot-v3.2.2 -b /dev -b /proc -b /etc/resolv.conf -r stage3-amd64-hardened+nomultilib-20140508 -0 emerge emacs

Current result:

Dumping under the name emacs
**************************************************
Warning: Your system has a gap between BSS and the
heap (140737334095608 bytes).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about
exec-shield in etc/PROBLEMS for more information.
**************************************************
emacs: Can't ftruncate (/var/tmp/portage/app-editors/emacs-24.3-r2/work/emacs-24.3/src/emacs): errno 22
make[1]: *** [bootstrap-emacs] Error 1

Note: this will be fixed once PRoot uses its own loader.

path.c:pop_component assertion failure on "/x"

The function pop_component in PRoot's path/path.c doesn't seem to correctly handle the case when the path argument has only one component, say "/usr". I can't figure out what the right thing to do in this case is, though: it seems like you would both want to leave the string as "/" and return "usr" as the last component, but there's no placement of a \0 byte that would have that effect. When the component is of length 2 or more, it seems like only the return address is affected: For instance on "/usr" it will set the string to "/" and return "sr" instead of "usr". But in the further corner case where the first component is only one character long, the assertion "assert(offset + 1 < length)" will fail causing PRoot to terminate.

Now that I understand this problem, I can work around it by never creating a root-level directory with a one-letter name when using PRoot. (I'd been in the habit of using "/t" as the name for a directory similar to "/tmp" but not bound to the outside /tmp.)

Conflict with glibc 2.18

In ./src/tracee/event.c you include sys/ptrace.h and linux/ptrace.h.

But since glibc , they add definition of ptrace_peeksiginfo_args in sys/ptrace.h which is too in linux/ptrace.h

So it conflicts with linux/ptrace.h

Changelog glibc : https://sourceware.org/git/?p=glibc.git;a=blob;f=ChangeLog#l2462

The error:

CC  tracee/event.o
In file included from ./tracee/event.c:27:0:
/usr/include/linux/ptrace.h:58:8: erreur: redefinition of ‘struct ptrace_peeksiginfo_args’
 struct ptrace_peeksiginfo_args {
        ^
In file included from ./tracee/event.c:26:0:
/usr/include/sys/ptrace.h:191:8: note: originally defined here
 struct ptrace_peeksiginfo_args
        ^

Cordialy,

Nicolas

Improve code coverage of PRoot.

Broken download link

The given link https://github.com/downloads/cedric-vincent/PRoot/proot-v0.7.1.tar.gz won't give anything useful.

Add an option to start a login shell instead of ``/bin/sh``.

aptitude crash at exit

The host is Debian jessie testing, with kernel 3.11-1-amd64. The proot version is 3.2. To reproduce it:

$ sudo debootstrap --include=aptitude wheezy rootfs
$ env -i LC_ALL=C PATH=/usr/bin:/bin:/usr/sbin:/sbin /tmp/PRoot-3.2/build/proot -w / -r rootfs aptitude --version
aptitude 0.6.8.2 compiled at Nov  7 2012 07:08:03
Compiler: g++ 4.7.2
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.10
  Ept support enabled.
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20110404
  cwidget version: 0.5.16
  Apt version: 4.12.0
*** glibc detected *** /usr/bin/aptitude-curses: double free or corruption (!prev): 0x000000004000f9f0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76d76)[0x7ffff54efd76]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7ffff54f4aac]
[0x7ffff7bf1064]
/lib/x86_64-linux-gnu/libc.so.6(__cxa_finalize+0xa5)[0x7ffff54b0175]
[0x7ffff7a51db3]
======= Memory map: ========
proot info: pid 6563: terminated with signal 6

This seems related to "a bug when using the ELF interpreter as a loader" as the comment in src/cli/proot.c. And yes Debian's aptitude is built with PIE.

I can also reproduce this on the host:

$ /lib64/ld-linux-x86-64.so.2 /usr/bin/aptitude-curses --version
aptitude 0.6.8.2 compiled at Aug 25 2013 12:37:10
Compiler: g++ 4.8.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.10
  Ept support enabled.
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20130608
  cwidget version: 0.5.16
  Apt version: 4.12.0
*** Error in `/usr/bin/aptitude-curses': double free or corruption (!prev): 0x00007fc99ac799f0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7aa26)[0x7fc997749a26]
/lib/x86_64-linux-gnu/libc.so.6(+0x7b7a3)[0x7fc99774a7a3]
[0x7fc99a0b2dc4]
/lib/x86_64-linux-gnu/libc.so.6(__cxa_finalize+0x8f)[0x7fc997708e3f]
[0x7fc999f05223]
======= Memory map: ========
(snip)

I see the roadmap says v3.4 would solve this kind of bugs. But I'm not sure if this is really the same bug as that of QEMU.

unix domain socket filepaths should be translated

Currently, paths for Unix domain sockets are not being translated to target paths..

This can prevent programs which depend on them to fail (which can cause filesystem errors which may not make sense to a user), or to need customized settings (e.g. tmux -S ./tmp/tmux, without / at beginning of filepath).

I think the fix would be to detect the bind system call when sockaddr.sun_family equals AF_UNIX, and then translate sockaddr.sun_path to a target filepath when it is found.

This came up while trying to use tmux on tal-dew on an Android phone. tmux tries to make a unix domain socket in /tmp, a directory Android does not have (in version 2.3 which I tested on).

QEMU 2.0.0 optionally requires libstdc++, which isn't always in the usual locations

Reported-by: @chewi
Ref.: https://groups.google.com/forum/#!topic/proot_me/OLbYgciCrPc

I'm on Gentoo but suspect this will affect other distributions too. Starting from 2.0.0, QEMU optionally requires libstdc++. If it detects a C++ compiler when building, it'll enable optional C++ code and the resulting QEMU binaries will be linked against that library. The trouble is that, at least on Gentoo, libstdc++ isn't under the usual locations such as /lib or /usr/lib but actually /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2 in my case. When proot tries to invoke QEMU, it bails out with...

libstdc++.so.6: cannot open shared object file: No such file or directory

The library is normally found at this path because of /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf (which is referenced by /etc/ld.so.conf). Evidently proot does not use ld.so.conf and relies on hardcoded paths instead. If I set LD_LIBRARY_PATH to this location before starting proot then it works but this is obviously not ideal. Could proot somehow use the host root's /etc/ld.so.conf?

Java fails to find libjli.so when run within PRoot

Running java -help (i.e. the java on $PATH) within PRoot results in an error:

/usr/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

On my Ubuntu system, /usr/bin/java is a symlink chain pointing at /usr/lib/jvm/java-6-openjdk/jre/bin/java, but running that executable (/usr/lib/jvm/java-6-openjdk/jre/bin/java -help) directly within the PRoot works without a problem.

Outside of the PRoot, on the main system, running java works without a problem.

Running ldd yields:
$ldd -v "/usr/bin/java"
linux-vdso.so.1 => (0x00007ffff7fdd000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ffff7d9e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffff7b7f000)
libjli.so => not found
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffff797b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffff75e5000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fde000)

Version information:
/usr/bin/java:
    libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
    libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
    libjli.so (SUNWprivate_1.1) => not found
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libpthread.so.0:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
    libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libdl.so.2:
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
    libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2

but unfortunately I can't run strace:
strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted

so I'm not sure how to go about continuing to debug.

The proot environment I have set up is as follows:

• /bin, /sbin, /dev, /etc, /lib, /usr and /proc are bound to the corresponding system directories.
• /home, /tmp, /var and /opt are empty directories
• '/lib64' is a symlink to '/lib' (same as on my real system)

Please let me know if you need any more info. Thanks!

New version is broken!

Hi!
When I want to start proot on my usual arm-rootfs it crashed:

proot -q qemu-arm ./rootfs/
Registering `cpu' which already exists
And it doesn't proot in the directory.

But it can be funnier:

proot -Q qemu-arm ./something-wrong
Segmentation fault

GDB

60 status = snprintf(result, PATH_MAX, "/proc/%d", tracee->pid);
(gdb) bt
#0 readlink_proc (tracee=tracee@entry=0x0, result=result@entry=0x7fffffff6310 "/proc/self",

base=base@entry=0x6180d8 "/proc", component=<optimized out>, component@entry=0x7fffffff6210 "self", 
comparison=PATHS_ARE_EQUAL) at ./path/proc.c:60

#1 0x00000000004061b1 in canonicalize (tracee=tracee@entry=0x0,

fake_path=fake_path@entry=0x7fffffff84f0 "/proc/self/mounts", deref_final=deref_final@entry=true, 
result=result@entry=0x6180d8 "/proc", nb_readlink=nb_readlink@entry=1) at ./path/canon.c:166

#2 0x000000000040623d in canonicalize (tracee=tracee@entry=0x0,

fake_path=fake_path@entry=0x7fffffffa6d0 "/etc/mtab", deref_final=deref_final@entry=true, 
result=result@entry=0x6180d8 "/proc", nb_readlink=1, nb_readlink@entry=0) at ./path/canon.c:195

#3 0x0000000000405c0a in init_bindings () at ./path/binding.c:571
#4 0x000000000040681a in init_module_path () at ./path/path.c:202
#5 0x0000000000401958 in main (argc=4, argv=0x7fffffffe8d8) at ./cli.c:449

(gdb) p tracee
0x0

Proot PATH search is broken when in another proot environment

Copy, chmod and run the test below:
env PROOT=/abspath_to/proot ./proot_path_test.sh

Here is the shell script:

#!/bin/sh                                                                                                                                                                                                        
#                                                                                                                                                                                                                
# Apparently when in a recursive proot context,                                                                                                                                                                  
# if the top proot does not habve the same PATH as the                                                                                                                                                           
# inner proot, the search for the inner proot-ed program                                                                                                                                                         
# will be done in the topmost proot PATH context.                                                                                                                                                                
#                                                                                                                                                                                                                
# This has the effect of not finding programs when the                                                                                                                                                           
# PATH is changed in the top proot sub process tree.                                                                                                                                                             
#                            
#                                                                                                                                                                                                                
# usage: env PROOT=/abspath_to/proot ./proot_path_test.sh                                                                                                                                                        
#                                                                                                                                                                                                                
PROOT=${PROOT-proot}

# Save PATH                                                                                                                                                                                                      
OLD_PATH="$PATH"

mkdir -p tmppath

# The executable that we want to run                                                                                                                                                                             
cat >tmppath/hello.sh <<EOF                                                                                                                                                                                      
#!/bin/sh                                                                                                                                                                                                        
echo hello                                                                                                                                                                                                       
EOF                                                                                                                                                                                                              
chmod 755 tmppath/hello.sh

# Test that it works                                                                                                                                                                                             
tmppath/hello.sh

# Test that it works from proot                                                                                                                                                                                  
$PROOT -r / tmppath/hello.sh

# Test that it works from proot of proot                                                                                                                                                                         
$PROOT -r / $PROOT -r / tmppath/hello.sh

# Set PATH to catch hello.sh                                                                                                                                                                                     
PATH=$PWD/tmppath:$PATH

# Test that it works from PATH                                                                                                                                                                                   
hello.sh

# Test that it works from proot                                                                                                                                                                                  
$PROOT -r / hello.sh

# Test that it works from proot of proot                                                                                                                                                                         
$PROOT -r / $PROOT -r / hello.sh

# Now change path in between and reset PATH                                                                                                                                                                      
PATH="$OLD_PATH"
cat >path_to_hello.sh <<EOF                                                                                                                                                                                      
#!/bin/sh                                                                                                                                                                                                        
PATH=$PAD/tmppath:$PATH                                                                                                                                                                                          
$PROOT -r / hello.sh                                                                                                                                                                                             
EOF                                                                                                                                                                                                              
chmod 755 path_to_hello.sh

# Test that it works                                                                                                                                                                                             
./path_to_hello.sh

# Oups, it is broken from proot                                                                                                                                                                                  
$PROOT -r / ./path_to_hello.sh

Perhaps mention on site/docs that PRoot requires a Linux-kernel host?

Hi there —

If I could gently make a suggestion for the PRoot website and/or docs, making an explicit mention of the fact that PRoot requires a Linux host?

While I know this might seem obvious, to the user of another POSIX based system, it actually isn't quite. While there are plenty of mentions of Linux guest filesystems, chroot, mount, and the ptrace system call itself are all common to all Unix-based systems, and neither talloc nor qemu are not Linux-specific either. This (well, for me, at least) is particularly confusing in light of what PRoot can do in terms of transparent use of incompatible architectures and binary formats. Myself, (probably being being far too hopeful, I suppose, as I'm in rather desperate need of a userland chroot on Darwin and fakechroot is also inextricable from glibc, so it seems), read the site and the manual through thoroughly and I believe there is, in fact, no mention that Linux is required host-side. But then, fatal error: 'linux/limits.h' file not found...

So I think it possibly might save some others like me a little bit of time (and a few dashed hopes), if you wouldn't mind noting this requirement somewhere?

:)
~G

Extract/run/remove a care archive in one command

It would be really hanldy to be able to extract, re-execute and remove the result of the extraction in only one command.

Something like:

./foo.bin
./foo/re-execute.sh
rm -rf foo/

Would be replaced by:

./foo.bin --extract-execute-remove

Support for x32 ABI on x86_64 is broken

How to reproduce:

proot-v3.2.2 -w / -r stage3-x32-20140508 true

Current result:

proot info: pid 21592: terminated with signal 11

Note: this used to work (c.f. commit 59349c4), maybe commit 677cd5a broke something (all PR_x32 definitions were removed by this commit, as well as PR_ARM ones)