Had to replace symlink with ro-bind to get minimal example to work

[harrypotterIUP]

trafficstars

README currently provides the following minimal example using --symlink for lib:

https://github.com/containers/bubblewrap/blob/9ca3b05ec787acfb4b17bed37db5719fa777834f/README.md?plain=1#L119-L126

As far as I understand it's based on demos/bubblewrap-shell.sh which also uses --symlink.

I kept getting

bwrap: execvp bash: No such file or directory

Which was resolved after replacing --symlink with --ro-bind. I believe this is connected to #200.

What's the downside? Thank you ❤️

[smcv]

The minimal example is sensitive to implementation details of your host OS, and is not guaranteed to work everywhere. Unfortunately, if we wrote an example that would work on every system, it would be far from minimal. The one in the README is an attempt at something that is "reasonably minimal" while still working on "most" systems.

Real-world production code to build a general-purpose bwrap command-line that is intended to work on any system looks more like https://github.com/flatpak/flatpak/blob/main/common/flatpak-exports.c and https://github.com/flatpak/flatpak/blob/main/common/flatpak-run.c, which has many good qualities, but "minimal" is certainly not one of them :-)

I kept getting bwrap: execvp bash: No such file or directory

On what version of what host operating system, with what configuration?

What's the downside?

If /lib64 is a symbolic link on your host system (as it is on e.g. Debian 12+, Fedora or Arch), then replacing --symlink with --ro-bind will convert /lib64 in the container from a symlink into a real directory (as though it was a recursive copy of /usr/lib64). This might be completely fine, or it might mislead some tool into having unintended behaviours - we cannot know every possible impact ahead of time, and we can't know what you're going to invoke inside the containerized shell.

[harrypotterIUP]

The minimal example is sensitive to implementation details of your host OS, and is not guaranteed to work everywhere. Unfortunately, if we wrote an example that would work on every system, it would be far from minimal. The one in the README is an attempt at something that is "reasonably minimal" while still working on "most" systems.

Of course. 👍

Real-world production code to build a general-purpose bwrap command-line that is intended to work on any system looks more like https://github.com/flatpak/flatpak/blob/main/common/flatpak-exports.c and https://github.com/flatpak/flatpak/blob/main/common/flatpak-run.c, which has many good qualities, but "minimal" is certainly not one of them :-)

Thanks for the links!

I kept getting bwrap: execvp bash: No such file or directory

On what version of what host operating system, with what configuration?

It was a legacy (intranet) server, running Ubuntu 18.04, I believe.

If /lib64 is a symbolic link on your host system

I can check that, but apparently /lib (and /bin, etc.) only became symlinks to /usr/... with Ubuntu 19.04.

I assume that explains having to use --ro-bind instead of --symlink. But why is the error so cryptic about it?

bwrap: execvp bash: No such file or directory

Why doesn't it simply say "/lib64 is not a symlink"?

[smcv]

why is the error so cryptic about it?

The only information that the kernel gives us is an error code, ENOENT. It doesn't give us any information about what it couldn't find.

Why doesn't it simply say "/lib64 is not a symlink"?

bubblewrap does not have enough context to know whether this is a problem, and it's a simple tool that does what its arguments tell it to do. If the result of those arguments is a working process, great; or if the result is a non-working process, it displays the string form of the error code that it was given and exits unsuccessfully. It can't invent information that it wasn't given.

Because bubblewrap is setuid root on some systems, every line of code we add is a security risk, so the cost/benefit for adding "did you mean..." is often not a good tradeoff. (Also, nobody has written that code.)