sandbox: stop mounting new filesystem on /tmp

From security perspective I also don't think protecting /tmp is significant while user $HOME which is much more valuable target is accessible.

@madaidan since you added this in !62 (closed), do you have any opinion?

Mounting a new tmpfs over /tmp isn't that big of a deal so it can be disabled if it's causing too many problems although I don't think many people will be cleaning files in /tmp.

If they are using it for tests, then they can use just that test with the --no-sandbox flag.

The command to run tests is python -m unittest discover -v (same as one run in mat2 CI), it doesn't accept --no-sandbox flag.

@georg it's inconvenient to have PR systematically broken because of the runner-thingy, do you think there is something we can do about this?

Sorry, I've a hard time to follow: Do you refer to the fact that the runner is private, and people have to enable the shared runners in their forks, first?

I think the problem is that bubblewrap tests always fail in fork pipeline.

I see, thanks for the hint. Unfortunately, I can't tell, as I didn't introduced the relevant code.

I guess, as of now, the bubblewrap call requires specific privileges, which are granted on our private runner (as this one is running containers privileged), however, it fails on the shared, public ones, due to the fact that containers running on these aren't privileged.

What to do?

Debug the bubblewrap call: check the required capabilities, and speak to the admins of the shared runners if it's possible to grant these.

or

Run the job in question only in the jvoisin/mat2 repo (which obviously has the drawback, that this change would reduce test coverage).

or

...

@jvoisin @georg could you merge this? It solves some issues reported by Arch Linux users. The other issue is #135 (closed)

merged

Merged in b2efffda, thanks!

@georg I'll run those MR locally, it's the easiest way :)

sandbox: stop mounting new filesystem on /tmp

Merge request reports

Activity