Proot error: Permission denied

[gldbrzent]

Any idea what I'm doing wrong?

bash [~]# junest
proot error: execve("/usr/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot-x86_64 --help`.
proot error: can't chmod '/tmp/proot-27735-4JIgCs': No such file or directory
proot error: execve("/usr/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot-x86_64 --help`.
proot error: can't chmod '/tmp/proot-27737-e6cTgt': No such file or directory
Error: Check if the junest arguments are correct and if the kernel is too old use the option junest -p "-k 3.10"

[fsquillace]

Hey,

I think the problem is due to the fact that proot is not capable to change permission in the tmp directory. Can you check which permission do you have in tmp?

I might need to add another section for this in the FAQs.

[gldbrzent]

well, to be honest I feel that there may be an os interaction that is run
by administrators in some cases..

if there is no proot approval in a whitelist scheme for bin/sh then there
could never have been the tmp file to begin with and so the tmp file does
not exist at the time of the error so error reporting for proot says it
can't change the permissions.

On Sun, May 29, 2016 at 1:57 AM, Filippo Squillace <[email protected]

wrote:

Hey,

I think the problem is due to the fact that proot is not capable to change
permission in the tmp directory. Can you check which permission do you have
in tmp?

I might need to add another section for this in the FAQs.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#148 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFczF3MT3jgwmK3Kz4frH-K9ZkGmyu2Eks5qGVTvgaJpZM4IpOrh
.

[fsquillace]

Interesting. I am not sure the whitelist approval. Have you also tried to create a file in tmp with your permissions? I remember I ve got such issue long time ago due to this.

[gldbrzent]

What would cause the /bin/sh or /usr/bin/sh to show as Permission denied in
proot's error reporting if it were not a whitelist issue in your opinion?

No I have not tried to create a tmp file.

Why would that demonstrate anything but deep farce in effect?

On Sun, May 29, 2016 at 2:23 AM, Filippo Squillace <[email protected]

wrote:

Interesting. I am not sure the whitelist approval. Have you also tried to
create a file in tmp with your permissions? I remember I ve got such issue
long time ago due to this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#148 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFczF4nFHJAZzSoaFTI8n_IOI47L70kOks5qGVsvgaJpZM4IpOrh
.

[gldbrzent]

bash []# nano /tmp/funfiles.txt
bash []# cat /tmp/funfiles.txt
hello world

bash [~]#

did work..

On Sun, May 29, 2016 at 3:22 AM, gldbrsentsa S.a. [email protected]
wrote:

What would cause the /bin/sh or /usr/bin/sh to show as Permission denied
in proot's error reporting if it were not a whitelist issue in your opinion?

No I have not tried to create a tmp file.

Why would that demonstrate anything but deep farce in effect?

On Sun, May 29, 2016 at 2:23 AM, Filippo Squillace <
[email protected]> wrote:

Interesting. I am not sure the whitelist approval. Have you also tried to
create a file in tmp with your permissions? I remember I ve got such issue
long time ago due to this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#148 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFczF4nFHJAZzSoaFTI8n_IOI47L70kOks5qGVsvgaJpZM4IpOrh
.

[gldbrzent]

This might help: On my system /usr/bin/sh does not exist but /bin/sh does..

Proot reported that /usr/bin/sh had a permissions error..

bash [~]# junest
proot error: execve("/usr/bin/sh"): Permission denied

Could this be because proot is trying to access /usr/bin/sh instead of $PATH/sh?

take a look at what my system reports when I try to run both in sequence:

bash [~]# /usr/bin/sh
bash: /usr/bin/sh: No such file or directory
bash [~]# /bin/sh
sh-4.1$ bash
bash [~]# 

Btw, if you let me know what script is initiating the proot that throws the error, I'll try my own fixes and then send them your way.

Also, as mentioned above there seems to be no permissions error with the tmp directory as long as the proot instance has not adopted some rogue set of credentials..

here's another copy of the /tmp directory test you suggested:

bash [~]# nano /tmp/funfiles.txt
bash [~]# cat /tmp/funfiles.txt
hello world

bash [~]#

my theory is the following line is proot's response to the file legitimately never having been created due to the sh issue..

proot error: can't chmod '/tmp/proot-27737-e6cTgt': No such file or directory

That temp file probably just isn't there due to the prior error..

Best luck, let me know if you'd like me to get in the script and make some test changes!
:)

[fsquillace]

junest is using /bin/sh to access to a shell. Also for me /usr/bin/sh does not exist but JuNest still works. JuNest does not do interfere at all with /usr/bin/sh.

[h4xhor]

Hi gldbrzent and fsquillace.
Firstly many thanks to fsquillace for open sourcing JuNest for us folks to use!

I've installed JuNest using the documented method 2.

I also have this same problem. On my system /bin/sh exists but /usr/bin/sh does not.

# cd ~/.junest/opt/proot

First I try using the existing build in /bin/sh

# ./proot-x86_64 /bin/sh
proot error: execve("/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot-x86_64 --help`.

Next I try using the one supplied with JuNest

# ./proot-x86_64 ~/.junest/bin/sh
proot error: execve("/home/sum/.junest/usr/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot-x86_64 --help`.

Now running the host's /bin/sh works

# /bin/sh
sh-4.1$

I am assuming that we need to be able to run JuNest successfully to run JuNest's own /bin/sh as ~/.junest/usr/lib/libncursesw.so.6 exists.

# ~/.junest/bin/sh
/home/sum/.junest/bin/sh: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory

[gldbrzent]

Hmm.. I'm wondering if this is a permissions issue that spans beyond the basic file rights.. does proot have a ghost os running that's setting more advanced whitelist/blacklist type permissions? It seems like proot and bin/sh as a team could come up with a nasty virtual environment pervasive enough to create a layer of os farce.. Just a thought.. :)

[fsquillace]

Thanks @h4xhor.

I feel proot provides an ambiguous error in these cases.
Proot would also require to specify the rootfs. Did you try to pass the root to junest via -R option?

[h4xhor]

Thanks fsquillace for the pointers, I tried

junest -p "-v 1 -R /home/sum/.junest"
proot warning: both '/home/sum/.junest' and '/home/sum/.junest' are bound to '/', only the last binding is active.
proot warning: both '/etc/host.conf' and '/etc/host.conf' are bound to '/etc/host.conf', only the last binding is active.
proot warning: both '/etc/passwd' and '/etc/passwd' are bound to '/etc/passwd', only the last binding is active.
proot warning: both '/etc/group' and '/etc/group' are bound to '/etc/group', only the last binding is active.
proot warning: both '/etc/nsswitch.conf' and '/etc/nsswitch.conf' are bound to '/etc/nsswitch.conf', only the last binding is active.
proot warning: both '/etc/resolv.conf' and '/etc/resolv.conf' are bound to '/etc/resolv.conf', only the last binding is active.
proot warning: both '/etc/localtime' and '/etc/localtime' are bound to '/etc/localtime', only the last binding is active.
proot warning: both '/dev' and '/dev' are bound to '/dev/', only the last binding is active.
proot warning: both '/proc' and '/proc' are bound to '/proc/', only the last binding is active.
proot warning: both '/tmp' and '/tmp' are bound to '/tmp/', only the last binding is active.
proot warning: both '/home/sum' and '/home/sum' are bound to '/home/sum', only the last binding is active.
... remaining output ommitted

Looking at the help from junest -p "--help" I also tried the -r switch to use ~/.junest "as the new guest root file-system"

junest -p "-v 1 -r /home/sum/.junest"
proot warning: both '/home/sum/.junest' and '/home/sum/.junest' are bound to '/', only the last binding is active.
... remaining output ommitted

I have tried increasing the verbosity with
junest -p "-v 2"
and the output is attached.
JuNestProotErr.zip

We see that around line 31 in the log file the same error:

proot error: execve("/usr/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
proot warning: process 269 is doing suspicious brk()
fatal error: see `proot-x86_64 --help`.

I noticed that I am able to run sh and bash if I cd into their directories first:

# cd ~/.junest/bin
[~/.junest/bin]# bash
[~/.junest/bin]# exit
exit
[~/.junest/bin]# sh
sh-4.1$ exit
exit
[~/.junest/bin]# cd ~/.junest/usr/bin
[~/.junest/usr/bin]# bash
[~/.junest/usr/bin]# exit
exit
[~/.junest/usr/bin]# sh
sh-4.1$ exit
exit

... but not if I run them from outside their bin directories

# cd ~/.junest/usr/
[~/.junest/usr]# bin/sh
bin/sh: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory
[~/.junest/usr]# bin/bash
bin/bash: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory
[~/.junest/usr]# cd ~/.junest/
[~/.junest]# bin/sh
bin/sh: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory
[~/.junest]# bin/bash
bin/bash: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory

So I think for some reason bash and bin can't see libncursesw.so.6 unless current working directory is the bin directory.

If we use ldd to find the dependencies of bash:

# cd ~/.junest/bin
# ldd bash
./bash: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./bash)
./bash: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ./bash)
    linux-vdso.so.1 =>  (0x00007fff181dd000)
    libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fdcf5fd5000)
    libncursesw.so.6 => not found
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fdcf5dd0000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fdcf5a3c000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fdcf581b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fdcf622d000)

We see that libncursesw.so.6 => not found is not found.

Now libncursesw.so.6 exists in ~/.junest/lib/ (for the guest) and in /usr/lib64/ (for the host). I think for some reason JuNest requires that libncursesw.so.6 exists also in /usr/lib (for the host) as well maybe?

[DiagonalArg]

Similar problem on CentOS. I don't have any trouble with sh as /usr/bin/sh exists and runs. I am also able to write my /tmp directory. I can even chmod u+x there.

$ junest
proot error: execve("/usr/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot-x86_64 --help`.
proot error: can't chmod '/tmp/proot-191251-QTPeBg': No such file or directory
proot error: execve("/usr/bin/sh"): Permission denied
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot-x86_64 --help`.
proot error: can't chmod '/tmp/proot-191253-c8L4He': No such file or directory
Error: Something went wrong with proot command. Exiting

$ uname -r
3.10.0-862.14.4.el7.x86_64

[buergi]

Same problem for me, does it has something to do with this proot-me/proot#79 ?

[buergi]

I got it working by reverting to the v4 version of proot, in my case the 64 bit version:

cd ~/.junest/opt/proot
mv proot-x86_64 proot-x86_64_v5
wget -O proot-x86_64 "https://github.com/proot-me/proot-static-build/blob/65c01c8f01b49e240c2f944367157b0987586190/static/proot-x86_64?raw=true"
chmod 755 proot-x86_64

[DiagonalArg]

@buergi's solution worked for me, too.

[LSaldyt]

@buergi's solution did not work for me, and I have the error (on RHEL) as everyone else has documented it.

[DiagonalArg]

I'll mention this as it may be an issue for others. While I was able to write to and chmod files in /tmp, I had (for other reasons) set TMPDIR to /home/me/tmp. Nevertheless, note my error message above:

proot error: can't chmod '/tmp/proot-191253-c8L4He': No such file or directory

Somehow proot is not tracking the TMPDIR variable.

(It seems this is a known issue.)

[jimdigriz]

Part of the problem is if you have /tmp mounted noexec; temporarily resolvable with mount /tmp -o remount,exec.

That prevents the "Permission denied", but then leads me to: error while loading shared libraries: somelib.so.6: cannot stat shared object: Invalid argument

[jimdigriz]

Just pulled and built the git tree (f30ce3e3c637d8c0fd1f453cc49eef1e897d7a8b) and it has fixed this for me; even displays a warning about TMPDIR being noexec

...also noticed I was using the Debian version of proot which is https://github.com/proot-me/proot; also works with the tip of master (c5a465e8d6a96237f1db285158abc4854db53e20) there too