singularity icon indicating copy to clipboard operation
singularity copied to clipboard

Singularity overwrites files on the host (/dev/) if they are available in the container

Open ghuls opened this issue 5 years ago • 9 comments

Version of Singularity:

singularity version 3.0.1-204.g1bc2e03b

Expected behavior

Singularity wouldn't change files on the host which are available in the container.

Actual behavior

Files on the host are changed.

Steps to reproduce behavior

Have a %setup section which extracts a tarball with a minimal rootfs: https://github.com/sylabs/singularity/pull/2465

which has /dev/shm with the following permissions: drwxr-xr-x On the host /dev/shm has the following permissions: drwxrwxrwt

Build the image.

Chrome will crash (as wel as other programs that use shared memory) as /dev/shm on the host now will have the following permissions: drwxr-xr-x.

I think this problem can be prevented by having another section than %setup, that creates a new rootfs dir (accessible with $SINGULARITY_ROOTFS) but does not bind mount /dev and other files and directories (%pre does not seem to support $SINGULARITY_ROOTFS).

Another example which will overwrite a file on the host:

$ cat busybox.def 
bootstrap: busybox
mirrorurl: https://www.busybox.net/downloads/binaries/1.28.1-defconfig-multiarch/busybox-x86_64

# Build busybox image
$ sudo singularity build busybox.sif busybox.def

# Backup hosts file.
sudo cp -a /etc/hosts /etc/hosts.original

# This will modify /etc/hosts on the host:
sudo singularity exec busybox.sif sh -c 'echo "111.111.111.111  test.com" >> /etc/hosts'

ghuls avatar Dec 14 '18 13:12 ghuls

@ikaneshiro

I think this is resolved by #2463. Is that correct?

jscook2345 avatar Dec 19 '18 16:12 jscook2345

@jscook2345 https://github.com/sylabs/singularity/pull/2463 does not resolve this.

ghuls avatar Dec 19 '18 16:12 ghuls

@ghuls

Sorry. Got my issues mixed up!

After discussion with a developer I believe that both of these behaviors are correct for the functionality provided by Singularity.

In the first case, with regards to /dev, it must be mounted writeable or else you would not be able to use some facets of the devices. Hence why when you change them in %setup and build your container as root, you can overwrite them.

In the second case, with regards to /etc/hosts, this is because the file is bind mounted when the image is executed. If you bind mount a file or directory, it will be writeable. And since you're modifying the file as root, it is overwritten.

Some directories and files are bind mounted by default (see /etc/singularity/singularity.conf).

Please let me know if you have any questions or comments. Thanks!

jscook2345 avatar Dec 19 '18 18:12 jscook2345

@jscook2345 OK, so if this is indented behaviour, it would be nice to have another stage than %setup in which an completely empty root filesystem dir is available, so it would be safe to write files there without risking overwriting files on the host (e.g. while extracting a rootfs tarbal). It would be great in %pre would support $SINGULARITY_ROOTFS.

ghuls avatar Dec 20 '18 15:12 ghuls

@ghuls Agreed. Ill try to get a PR up to support this shortly.

ikaneshiro avatar Dec 21 '18 17:12 ikaneshiro

@ikaneshiro Any progress on this? Also https://github.com/sylabs/singularity/issues/2538 seems to run into problems with bind mounted files.

ghuls avatar Jan 17 '19 21:01 ghuls

Hello,

This is a templated response that is being sent out to all open issues. We are working hard on 'rebuilding' the Singularity community, and a major task on the agenda is finding out what issues are still outstanding.

Please consider the following:

  1. Is this issue a duplicate, or has it been fixed/implemented since being added?
  2. Is the issue still relevant to the current state of Singularity's functionality?
  3. Would you like to continue discussing this issue or feature request?

Thanks, Carter

carterpeel avatar May 15 '21 16:05 carterpeel

This issue has been automatically marked as stale because it has not had activity in over 60 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jul 14 '21 17:07 stale[bot]

@ghuls Still getting this problem ? Have this been solved already ? If yes, what work around have you followed and applied ?

We're looking into the issue carefully, soon will bring to community and discuss ways to better solve as well address this. Thankyou for keeping the interest in the subject.

pedroalvesbatista avatar Jul 15 '21 01:07 pedroalvesbatista

Copied to https://github.com/apptainer/apptainer/issues/793

kmuriki avatar Oct 17 '22 03:10 kmuriki