singularity
singularity copied to clipboard
Singularity overwrites files on the host (/dev/) if they are available in the container
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'
@ikaneshiro
I think this is resolved by #2463. Is that correct?
@jscook2345 https://github.com/sylabs/singularity/pull/2463 does not resolve this.
@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 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 Agreed. Ill try to get a PR up to support this shortly.
@ikaneshiro Any progress on this? Also https://github.com/sylabs/singularity/issues/2538 seems to run into problems with bind mounted files.
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:
- Is this issue a duplicate, or has it been fixed/implemented since being added?
- Is the issue still relevant to the current state of Singularity's functionality?
- Would you like to continue discussing this issue or feature request?
Thanks, Carter
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.
@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.
Copied to https://github.com/apptainer/apptainer/issues/793