proot-me / proot Goto Github PK
View Code? Open in Web Editor NEWchroot, mount --bind, and binfmt_misc without privilege/setup for Linux
Home Page: https://proot-me.github.io
License: GNU General Public License v2.0
chroot, mount --bind, and binfmt_misc without privilege/setup for Linux
Home Page: https://proot-me.github.io
License: GNU General Public License v2.0
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.
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
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().
proot warning: process 4183 is doing suspicious brk() Running ePSXe emulator version 1.9.4. [...]
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.
Reference: #46 (comment)
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.
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.
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.
"Multicall" binaries (busybox
, for example) are not being run correctly for certain PATH
s.
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
)
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
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.
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
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
[...]
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.
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.
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
Checking whether setuidx is available : samba-4.1.0/source3/wscript:997: error: the configuration failed (see 'samba-4.1.0/bin/config.log')
How to reproduce:
$ proot bash
$ emacs
^Z
[1]+ Stopped emacs
Expected behavior: emacs is stopped.
Actual behavior: emacs still runs.
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.
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.
When compiling proot 3.2.1 in Gentoo i have such warning:
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.
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...
This works: sh -c 'echo test | cat /dev/stdin'
This doesn't: proot sh -c 'echo test | cat /dev/stdin'
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.
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:
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
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.
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?
Something like that:
proot [bindings] -x /usr/local/bin
or maybe:
proot [bindings] readlink /proc/proot/detranslate/usr/local/bin
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.
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.
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.)
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
The given link https://github.com/downloads/cedric-vincent/PRoot/proot-v0.7.1.tar.gz won't give anything useful.
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.
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).
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?
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 directoriesPlease let me know if you need any more info. Thanks!
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
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.