-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't mount more filesystems within a read-only mount #413
Comments
Note that So, if you instead mount children of example.sh #!/bin/bash
args=()
shopt -s dotglob
for d in /*; do
args+=("--dev-bind" "$d" "$d")
done
bwrap "${args[@]}" "$@" $ ./example.sh --bind $(mktemp -d) /test stat /test
File: /test
Size: 4096 Blocks: 8 IO Block: 4096 directory An in general you can do It would be nice though if we don't have to use a wrapper script for it. And also using many --bind's is slow (#384) |
Sure, this works for directories, however it stops working if files are present in e.g.
|
It works for files too |
Can you share the corresponding shell script allowing files in |
It's the same...
Is there anything special about your root-level file? |
@haampie: What if the file or directory B to inject into directory A is several layers below A? More concretely, I'd like to have directory With the above approach, I'd need to bind mount Or have I missed something here? |
Yep, at least in this particular case: Debian's But in general it would be nice to have some tool to blend one directory into another without a lot of fuss ... |
In general, bubblewrap is a low-level tool which tries to do what you ask for, even if what you ask for can't work. We don't have the opportunity to change the kernel's behaviour, and the kernel won't allow mounting something if there is no mount point, so all we can do is try to create mount points.
Yes (and this is how Flatpak implements
I think #412 will probably already make this possible, without needing new options: mount the read-only directory (
Merge requests welcome, although I don't think it will necessarily be straightforward. Please bear in mind that bwrap is setuid root on some systems, so anything that is added to bwrap needs to be hardened against malicious users crafting a command-line to try to elevate privileges to root, which limits the dependencies and complexity that can be accepted. It's often better to put the mechanism in bwrap (make things possible, but not necessarily easy), and have a higher layer like Flatpak that is the policy (take a "do what I mean" high-level goal and turn it into potentially many bwrap command-line options). Flatpak's |
Wouldn't the bwrap --bind / / --bind . /here true --remount-ro / The only downside I see is that the mountpoints that bubblewrap creates are still there afterwards. |
@xi: If the mount point Again, bubblewrap is mechanism more than policy, so it can't know whether that's acceptable or not; implementing your desired policy is a job for a higher-layer thing like Flatpak or your |
Simple example:
This can be worked around by creating the target directory for the second mount inside the root of the first mount, or by using something like overlayfs.
If there was a way to work around this in bubblewrap itself, it would be nice, but I'm not sure it's possible. Maybe if overlayfs integration gets added (#412), there could be an option for a "semi-read-only" mount to avoid this issue.
Also, maybe there could be some sort of warning with hints to resolve it if this situation is detected?
While there may not be any practical solution, I'm partly also posting this so anyone else who has this issue doesn't need to spend their weekend debugging it.
The text was updated successfully, but these errors were encountered: