5

I have a shell script like so:

#/bin/sh
#do some stuff

But the interpreter, sh is not in /bin/ but instead in another directory. Similarly, the script creates folders in directories I have no write access to. I've replaced the directory sh is in using sed but with loads of scripts depending on one another, I can't change all the possible directories they may create.

Is there any way to emulate a filesystem/ read/writes so the script may be sandboxed and can do what it pleases, similar to what Sandboxie does in Windows?

user230152
  • 51
  • Using chroot to give the script a displaced root directory would work, but would require you to populate the hierarchy with all the associate infrastructure (any executables used, the needed shared libraries, and necessary device files). Another way would be to rewrite the script to require relative paths throughout, rather than absolute paths. This may or may not be possible, of course. – Kusalananda May 06 '17 at 12:06
  • @Kusalananda Thank you! I will use proot and bind the directories the required stuff are in. If you can write your comment as an answer I can accept it :) – user230152 May 06 '17 at 12:21
  • On Debian derived systems there is fakeroot and friends – Chris Davies May 06 '17 at 12:22
  • Did you mean #!/bin/sh instead of #/bin/sh. There is a significant difference. Without the ! your first line is just a comment. – Tigger May 07 '17 at 06:45

3 Answers3

7

What you're looking for is, at least, a chroot environment, i.e. running a program with access only to a subtree of the system's directory tree. Note that chroot only applies to filesystem accesses, it doesn't confine the process in any other way: a process in a chroot can still access the network, debug programs outside the chroot, etc.

The chroot confines filesystem accesses even through symbolic links: if you have a symlink that points outside the chroot, then when accessed from a chrooted process, an absolute symlink goes from the root of the chroot, and a relative symlink with .. doesn't go any further up than the root of the chroot. So to assemble a chroot containing files in separate locations, you can't use symlinks. You can use bind mounts, copy files (but this takes space and they aren't updated automaitcally), or use hard links (but this is inconvenient to set up and can't be done across filesystems).

The chroot system call can only be invoked by root. As a non-root user, you can use fakechroot instead. This only works on programs that are dynamically linked (which is most of them). Fakechroot can assemble a directory tree from several locations, so often you don't need to use bind mounts (but if you do need a bind mount, you can use bindfs without root privileges).

Gilles 'SO- stop being evil'
  • 829,060
-1

give yourself a working bin directory, copy the script in there, and replace the directory names with surrogates.

in your .profile

ORIGINAL_PATH=${ORIGINAL_PATH:=$PATH}
PATH=$HOME/bin:${ORIGINAL_PATH}
export ORIGINAL_PATH

guarantees you always have a consistent PATH,

then at the command line:

$ mkdir $HOME/bin
$ cp {the script you need} $HOME/bin
$ pushd $HOME/bin
$ vi {the script}

changing the names of those unwriteable directories to something you can get at. so, you might:

$ pushd      # might take you HOME, if not cd $HOME
$ mkdir sbox # your "sandbox"
$ pushd sbox 
$ mkdir -p a/path/to/a/previously/unwriteable/ ...

this latter creates a directory:

 $HOME/sbox/a/path/to/a/previously/unwriteable/

I've found it useful to use positional parameters, rather than cutting and pasting longwinded file paths. If you're going to use a name repeatedly, then do something like this:

$ set /DIR/Whichheld $HOME/sbox a/path/to/a/previously/unwriteable filename
$ echo $# $*

then this

$ cp $1/$3/$4 $2/$3/$4

takes care of one file. If you're needing a lot of copies:

$ from=$1/$3
$ to=$2/$3
$ pushd $from
$ cp * $to
$ popd 
$ pushd $to

will copy all the files in FROM to TO...

and good luck.

Marty McGowan
  • 139
-2

use ns. nuff sed.

it demonstrates a way of hiding a directory like:

mkdir /tmp/dir && {
    rm "$_" && cd /dev/fd/3
} 3</tmp/dir

aside - sorry, ive either come into a very sophisticated years-long hoax, or deity, and so have had issues with sign-ons and keeping a computer more that.

anyway, take care!

vres3Kim
  • 3