How to Run a Command in a Chroot Jail Not as Root and Without Sudo

How to run a command in a chroot jail not as root and without sudo?

If you invoke chroot from root, the chroot option --userspec=USER:GROUP will run the command under the non-root UID/GID.

By the way, the option '--userspec' is first introduced in coreutils-7.5 according to a git repository git://git.sv.gnu.org/coreutils.

How to execute linux command in a chroot jail

Either the binaries you copy in to your chroot environment must be statically linked, or you need to copy in the necessary shared libraries as well (/lib / /usr/lib).

Non-root processes can execute in a chroot environment just as root processes can, but only root processes can call chroot() so you will need to have a root process set up the chroot environment and then switch to the unprivileged user id.

How unshare makes possible to use chroot without real root?

This happens because unshare(2) is called first, and it's passed CLONE_NEWUSER as one of the flags bceause of -U. The manual remarks about that flag:

Unshare the user namespace, so that the calling process is moved into a new user namespace which is not shared with any previously existing process. As with the child process created by clone(2) with the CLONE_NEWUSER flag, the caller obtains a full set of capabilities in the new namespace.

Now that the process has a full set of capabilities in the new namespace, it can call chroot(2). Note that that call occurs before the process with mapped IDs is invoked, so at that point, the process is still privileged in the new user namespace. The capabilities are dropped upon the execve call to start the new process.

That's why your chroot command fails: because it lacks permissions, whereas the unshare command is still privileged before it invokes any process.

Detecting a chroot jail from within

The inode for / will always be 2 if it's the root directory of an ext2/ext3/ext4 filesystem, but you may be chrooted inside a complete filesystem. If it's just chroot (and not some other virtualization), you could run mount and compare the mounted filesystems against what you see. Verify that every mount point has inode 2.

chroot error: failed to run command ‘PATH=/bin:/usr/bin:/sbin:/usr/sbin’: No such file or directory

In bash, you need

PATH=/bin:/usr/bin:/sbin:/usr/sbin chroot /home/matrix1/LuMi/linuxrootdir

Is it possible to run users' jobs in chroot environment using Slurm

I do not want each user to have any read/write access to the other users' files and important files such as /etc/passwd.

It is normal for users to be allowed to read /etc/passwd, it is necessary for many operations. Sensitive information such as password hashes, which originally were stored in /etc/passwd, are nowadays stored in /etc/shadown in all Linux distributions.

I observe that when any slurm-job runs under a new user, it can read all files under the root (/) directory such as /etc/passwd.

Again, it is normal for regular users to be able to read files in / ; it enables them to access installed software, see information about their processes, etc.

Only /root should be readable by root only.

As for the files of other users, they will typically be in /home so make sure that the sub-directories in /home are 700 are are owned by their respective users.

Files in /etc might also hold sensitive information, but package managers often make sure the proper permissions are set on this files.

If you are concerned about privacy, you should also configure Slurm to disable node sharing and to keep accounting information private. See more information here.

---

Related Topics