Running singularity with sudo mounts /root RW into container

[Trey Dockendorf]

On our systems we give staff sudo access to singularity to build images and have discovered that some applications built were modifying PATH in /root/.bashrc which caused all sorts of problems when dealing with applications that affect Python functionality on RHEL systems.  I know for standard users when "mount home = yes" is set then my $HOME will be in container but should this be the case for root?  Is there a way to selectively tell Singularity to not mount $HOME into the container for something like the "shell" subcommand?  Below is the behavior we'd like to avoid.  I was able to redefine home by passing "--home /var/tmp:/root" but this seems like an ugly hack.  Ideally we'd either be able to disable "mount home" just for root or we'd be able to disable just the home mount at command line, but not seeing such an option in help output for "shell" subcommand.  This is Singularity 2.4.6 on RHEL 7.4.

Thanks,

- Trey

$ sudo singularity shell ~/singularity/centos7.img 

Singularity: Invoking an interactive shell within container...

Singularity centos7.img:~> pwd

/root

Singularity centos7.img:~> ls

<Contents of system's /root>

Singularity centos7.img:~> touch mytest

[root@owens-rw02 ~]# stat /root/mytest 

  File: ‘/root/mytest’

  Size: 0               Blocks: 0          IO Block: 65536  regular empty file

Device: 23h/35d Inode: 3054865482  Links: 1

Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Access: 2018-04-26 09:30:04.623682000 -0400

Modify: 2018-04-26 09:30:04.623682000 -0400

Change: 2018-04-26 09:30:04.623682000 -0400

 Birth: -

[Trey Dockendorf]

Discovered --contain which resolves the issue to some degree but still seems odd that root's home directory was mapped automatically.

We're also disallowing sudo execution of singularity on our read-write hosts.

- Trey

[Dave Godlove]

Hey Trey,

I'll give you my $0.02.  I think that allowing image building on a production system is not really in line with the Singularity philosophy.  (Though I defer to Greg who originally wrote Singularity to spell out what the philosophy actually ought to be.)  But imho you should have a "production system" where you run your containers and a "build system" where you create your containers.  Ideally the "build system" should be a system that you fully control.  A VM, or AWS instance or something would work well for this.  Then after the image is built you can copy it to you "production system".  

Would this model work in your environment, or is there something preventing it (like an air-gapped secure system)?

Dave

--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.

[Trey Dockendorf]

We plan to take this approach but for the time being have been doing builds on the production systems.  Our work around of only allowing builds on compute within interactive jobs should be sufficient until we get a proper build host.  Our compute have read-only root filesystems served up via NFS so there is not much someone with root can change if they were to bind mount locations they shouldn't.

Thanks,

- Trey

To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.

--
You received this message because you are subscribed to a topic in the Google Groups "singularity" group.
To unsubscribe from this topic, visit https://groups.google.com/a/lbl.gov/d/topic/singularity/NKKHeqFrh_c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to singularity+unsubscribe@lbl.gov.

[v]

If you like /use Google Cloud you can check out the builders! 

https://singularityhub.github.io/sregistry-cli/client-google-compute

You can customize your builders with a config.json, and we can also add other backends to the library if this is desired (for example, if you have some kind of cluster, AWS, or just local resource). For other services it's just a matter of working with the various APIs. I'm planning on doing a simple workflow for Singularity Registry Server to do:

recipe in github repo --> continuous integration (with testing) to build --> push to Singularity Registry Server

Working on the middle bit right now. Actually, the problem is much simpler than that, when you think about it, and this is what makes it so fun! We generally have:

recipe under version control ---> build and test --> storage --> retrieve

which means as academic and research groups, we have great flexibility to customize each of those steps, mix and match, and switch out when we change our minds. Which you know, never happens right? :P

To unsubscribe from this group and all its topics, send an email to singularity...@lbl.gov.

--
You received this message because you are subscribed to the Google Groups "singularity" group.

To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.

--

Vanessa Villamia Sochat
Stanford University '16

(603) 321-0676