📄 Building without root access

There are situations where root access is not given, however, do not worry, there are 3 options to choose from:

Use –fakeroot.

Use proot.

Use Singularity Container Services.

A fake root user has almost the same administrative rights as root but only inside the container and the requested namespaces.

All files or directories created by the fake root user are owned by root:root inside the container, and user:group outside of the container. Let’s consider the following example, in this case “user” is authorized to use the fakeroot feature and can use 65536 UIDs starting at 131072 (same thing for GIDs).

Restrictions are also applied to networking, if singularity is executed without the --net flag, the fake root user won’t be able to use ping or bind a container service to a port below 1024.

The --fakeroot option is only available with the following commands:

shell

exec

run

instance start

build

Let’s build the SIF image from the previous Lab 3:

As you can see, the build is completed without having to rely on root or administrative access. However take into consideration this feature is only available for operating systems with linux kernel version 3.18 and newer, if your kernel is older, then your next option is to use proot.

SingularityCE 3.11 introduces the ability to run some definition file builds without –fakeroot or sudo. This is useful on systems where you cannot sudo, and the administrator cannot perform the configurations necessary for –fakeroot support.

Unprivileged proot builds are automatically performed when proot is available on the system and singularity build is run by a non-root user against a definition file, so no flags need to be passed on to the singularity command.

Installing proot is out of the scope of this tutorial. It is important to remark that this method comes with its limitations because administrative user (root) emulation is not complete, so let’s evaluate the definition file first and determine if it is worth using this method.

Do not support arch / debootstrap / yum / zypper bootstraps. Use localimage, library, oras, or one of the docker/oci sources.

Do not support %pre and %setup sections of definition files.

Run the %post sections of a build in the container as an emulated root user.

Run the %test section of a build as the non-root user, like singularity test.

Are subject to any restrictions imposed in singularity.conf.

Incur a performance penalty due to the ptrace-based interception of syscalls used by proot.

May fail if the %post script requires privileged operations that proot cannot emulate.

If your system have proot installed, you might get an output similar to this:

Note

SingularityCE automatically calls proot for you and performs the build. To know if proot is installed, it is typically installed in a directory listed in the $PATH environment variable, issuing which proot command will let you know if it is installed.