Make running directory available

[bbockelm]

When combined with NO_NEW_PRIVS (#149), it should be safe to make the $PWD where singularity is invoked available inside the image.

This would be useful when integrating singularity with HTCondor; HTCondor creates a per-job working directory in /var/lib/condor/execute/dir_$PID. I would like only that directory available inside the container (and not all the other working directories of unrelated jobs).

Alternately, instead of the running directory available, allow a user-provided list of bind mounts on the command line.

[gmkurtzer]

This was the normal operating mode of 2.0, but I was asked by system administrators to change this model so they have full control of what host directories can potentially be binded into the container.

In theory (and if I am understanding correctly), /var/lib/condor could be binded inside the container via the config file and while it is a brute force method, would suffice? maybe?

Another limitation as Singularity currently stands (but hopefully will have a patch shortly to help with this) from @aduffy19, is that the bind point must exist inside the container for a bind to work. Without having /var/lib/condor/execute/dir_$PID already existing within the container and no writable means to create it... it might be a non-starter.d

Thoughts?

[bbockelm]

Yeah - I think the introduction of PR_NO_NEW_PRIVS and/or MS_NOSUID on bind mounts would alleviate concerns I would have about arbitrary bind mounts. Even then, I think it would be a solid idea to have this feature default to off and be something specified in the config file.

Good to hear someone was already working on bind mounts of non-existing directories. I was dreading having to write that for this :). Is there a ticket yet for that?

[gmkurtzer]

I would agree about the NO_NEW_PRIVS and NOSUID alleviating the issue with arbitrary bind mounts, and making it configurable as you suggested would be perfect and fairly trivial to do once we have a substrate to create the necessary directories for the bind mounts.

[kenneth59715]

I am wanting something similar to this specifiable by the user invoking singularity. The current working directory available in the image,but nothing else mounted. Maybe an option to not mount directories that are listed in singularity.conf bind path?

[gmkurtzer]

Something like this?

$ singularity exec  -C -B `pwd` ~/container.img pwd
/home/gmk/git/ompi/orte/mca/schizo/singularity
$ singularity exec  -C -B `pwd` ~/container.img ls | wc -l
11

We are requesting to be contained (-C) and then doing a user bind mount (-B) of pwd.

If so, this is supported in master.

[kenneth59715]

Yes, that would be perfect. I assume it will be in the next release? Is there any way to get informed when the next release happens?

Kenneth

On Fri, Sep 02, 2016 at 07:41:11AM -0700, Gregory M. Kurtzer wrote:

Something like this?

$ singularity exec  -C -B `pwd` ~/container.img pwd
/home/gmk/git/ompi/orte/mca/schizo/singularity
$ singularity exec  -C -B `pwd` ~/container.img ls | wc -l
11

We are requesting to be contained (-C) and then doing a user bind mount (-B) of pwd.

If so, this is supported in master.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/gmkurtzer/singularity/issues/150#issuecomment-244394102

[gmkurtzer]

Yes, it will be in the next release... But, it is slightly dependent on the host's abilities. For example, it depends on the host's ability to support the overlayfs file system.

What distribution/release is running at your site?

[kenneth59715]

We're running some level of CentOS. Not sure which.

[kenneth@comet-ln2 log]$ dmesg | grep -i centos

Linux version 2.6.32-573.12.1.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Dec 15 21:19:08 UTC 2015

On Fri, Sep 02, 2016 at 01:46:29PM -0700, Gregory M. Kurtzer wrote:

Yes, it will be in the next release... But, it is slightly dependent on the host's abilities. For example, it depends on the host's ability to support the overlayfs file system.

What distribution/release is running at your site?

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/gmkurtzer/singularity/issues/150#issuecomment-244483353

[gmkurtzer]

It looks like Centos 6. To be sure: cat /etc/redhat-release

If that is infact the case, the bind feature probably won't work as the kernel does not support overlay file systems. But you might be able to use the -H parameter (also in conjunction to --contain) to virtualize your home file system, but I'm not sure that will give you exactly what you were hoping... Maybe will bring you close though by limiting scope?

[kenneth59715]

[kenneth@comet-ln2 ~]$ cat /etc/redhat-release CentOS release 6.7 (Final) [kenneth@comet-ln2 ~]$

What's the meaning of "virtualize" in this context? Is the whole filesystem unaffected outside the container? Or visible and writable inside the container? I need a writable pwd, without having anything above that writable...

On Fri, Sep 02, 2016 at 07:50:58PM -0700, Gregory M. Kurtzer wrote:

It looks like Centos 6. To be sure: cat /etc/redhat-release

If that is infact the case, the bind feature probably won't work as the kernel does not support overlay file systems. But you might be able to use the -H parameter (also in conjunction to --contain) to virtualize your home file system, but I'm not sure that will give you exactly what you were hoping... Maybe will bring you close though by limiting scope?

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/gmkurtzer/singularity/issues/150#issuecomment-244522470

[gmkurtzer]

What the -H parameter does is change the user's home directory for a different arbitrary directory that the user owns on the file system. While this isn't doing exactly as you requested by making the current directory shared into the container, when used with the --contain/-C option I think it will do what you are looking for. For example:

$ mkdir ~/container_home
$ echo "Hello" > ~/container_home/test_file
$ singularity shell -C -H ~/container_home /tmp/Centos-7.img
Singularity.Centos-7.img> pwd
/home/gmk
Singularity.Centos-7.img> cat test_file
Hello
Singularity.Centos-7.img> 

[kenneth59715]

Is anything above the -H specified directory visible within the container? The -H is not available in the release we're using now. I assume it's in the next release?

[gmkurtzer]

Hi Kenneth,

Just to make sure I answer your question correctly, I will articulate a few things. The -H option only pertains to the home directory within the container. If you do a "cd; ls ../" You will not see or have access to anything above related to the user's home. But you will still of course have access to any other bind points within the container. If you want to limit them, you would also have to provide the -C option.

Lastly, this feature is in the current master branch of Singularity and is slated to be released as part of 2.2 (in about 2-4 weeks). If you are able, it would be fantastic if you can test it! :)

[kenneth59715]

That sounds like it will do what I want. I'll ask the sys admins to install, when 2.2 is out.

[gmkurtzer]

Fantastic!

BTW, I am going to close this issue as the original issue has been resolved in the 2.2 code.

Greg