1

I am running into a special issue (maybe a bug) when using Bindfs and chroot. I have created a sample sandbox directory which contains nodejs and all of its dependencies so as to be able o run inside the chroot jail.

Well, what I do is creating a temporary directory, inside of which I mount the following directories from the sample sandbox

  • bin
  • dev
  • etc
  • include
  • lib
  • lib64
  • libexec
  • usr

To mount my directories I use bindfs, using the following command template

bindfs -u nobody -g nobody -p a-w:a+rx --chown-ignore --chgrp--ignore --chmod-ignore :sample-sandbox/:dir :new-sandbox/:dir

So, I go to the above directory by doing cd :new-sandbox and execute the following command (65534 is the uid of nobody)

chroot --userspec=65534 . node

I get the following error response

chroot: failed to run command `node': Permission denied

When I run chroot . node, I get the node console, as I should. The fun part is that when I run ls inside the directory I get the following response which indicates that files and folders are owned by user nobody (as I declared in my bindfs command).

total 32
dr-xr-xr-x 4 nobody nobody 4096 Apr 15 12:46 bin
dr-xr-xr-x 2 nobody nobody 4096 Apr 10 14:56 dev
dr-xr-xr-x 2 nobody nobody 4096 Apr 15 16:33 etc
dr-xr-xr-x 5 nobody nobody 4096 Apr 12 02:21 include
dr-xr-xr-x 9 nobody nobody 4096 Apr 12 02:21 lib
dr-xr-xr-x 4 nobody nobody 4096 Apr 12 02:22 lib64
dr-xr-xr-x 3 nobody nobody 4096 Apr 12 02:22 libexec
dr-xr-xr-x 6 nobody nobody 4096 Apr 12 02:22 usr

When I am trying to do the same inside the prototype sandbox which has the original folders and not ones mounted with bindfs, everything goes fine, even when executing as user nobody.

Do you have any idea why this happens and how this could be resolved? Thank you very much.

P.S. Please do not prompt me to use Linux Containers or Virtual Machines or any other alternative technology to the one I 'd like to use.

Paris
  • 6,323
  • 7
  • 31
  • 49

1 Answers1

1

I found out that the :new-sandbox had permissions only for its creator (that's what Python does, when using tempfile.mkdtemp).

So allowing others and group to read and execute inside that directory solved the issue.

Paris
  • 6,323
  • 7
  • 31
  • 49