I am aware, that Singularity needs setuid attributes for at least one of its installation files. This attribute cannot be set by non-root user. Is there any walkaround of this problem, even with the cost of reduced functionality?
There are many HPC environments, where there is no Singularity (most of them in my experience), where users would benefit from the Singularity the most.
@adamryczkowski You can disable setuid at build time by using ./configure --disable-suid --prefix=/where/you/have/rights. Disable setuid requires a kernel >= 3.8
Is there documentation anywhere that explains why singularity needs root for installation? Why can't it just be a standalone binary?
Edit: I found by looking through the code + other issues that if user namespaces are not supported, and the executable has not been setuid 0, then singularity will fail with the error "Failed invoking the NEWUSER namespace runtime: Invalid argument".
Hi there,
Singularity is a standalone binary, (or at least a set of standalone
binaries). But it needs an SUID bit to work properly. That is because
some of the things Singularity does on a user's behalf (like mounting
images to the loop device) require escalated privs.
This might give you more info:
http://singularity.lbl.gov/docs-security
On Wed, Jan 24, 2018 at 4:08 PM, maxogden notifications@github.com wrote:
Is there documentation anywhere that explains why singularity needs root
for installation? Why can't it just be a standalone binary?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/singularityware/singularity/issues/1258#issuecomment-360273817,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHUUXBPciAMMweuODfVkENgu9Mor53LEks5tN5vGgaJpZM4RicCk
.
I compiled and installed Singularity 2.6.0 in my home directory using ./configure --disable-suid --with-userns. When I run singularity run shub://GodloveD/lolcow I get the error message:
ERROR : Failed invoking the NEWUSER namespace runtime: Invalid argument
ABORT : Retval = 255
Can Singularity be used without root and setuid permissions? I don't have root access. I'm on an HPC system with CentOS 7.4.1708 and Linux kernel 3.10.0-693.5.2.el7.x86_64.
@sjackman I don't believe that RHEL 7.4 fully supports user namespace, or at least it isn't fully enabled yet. The user space code is there, but it's still an experimental feature, until 7.5 (I think). To enable, the kernel needs to be booted with the option:
namespace.unpriv_enable=1
Actualy it is a technology preview in both RHEL 7.4 and 7.5. In addition to the boot parameter, you also need to set sysctl user.max_user_namespaces = 15000 (or some other non-zero number). The boot parameter is no longer needed in RHEL 7.6 (which is in beta now).
Thanks for the information! So non-root Singularity is expected to work out-of-the-box with CentOS 7.6?
Yes, without the singularity features that still require setuid root (for example mounting image files -- sandboxes will work without setuid).
Excellent. I like forward to the release of CentOS 7.6 then. Hopefully our systems group will upgrade to it.
Is there a way to disable-suid in Singularity 3.0 as well, as now it uses mconfig?
There's not an mconfig option, although I think that is a good idea. I suggest making a separate issue for that. The workaround is to remove libexec/singularity/starter-suid after make install. That's what I do and I know it works.
Another workaround that will work starting in 3.0.3 is to set 'allow setuid = no' in singularity.conf. Then if starter-suid is really installed as setuid-root there's still a small risk of vulnerability, but if starter-suid is invoked manually (since singularity won't invoke it) it will exit very early so the risk is quite low. This is the recommended way to go when using a prebuilt package such as an rpm.
See docs at: https://sylabs.io/guides/3.5/admin-guide/installation.html#install-nonsetuid
Most helpful comment
There's not an mconfig option, although I think that is a good idea. I suggest making a separate issue for that. The workaround is to remove libexec/singularity/starter-suid after make install. That's what I do and I know it works.
Another workaround that will work starting in 3.0.3 is to set 'allow setuid = no' in singularity.conf. Then if starter-suid is really installed as setuid-root there's still a small risk of vulnerability, but if starter-suid is invoked manually (since singularity won't invoke it) it will exit very early so the risk is quite low. This is the recommended way to go when using a prebuilt package such as an rpm.