Previously, mounting a socket over the top of an existing socket
would fail, because create_file() opens it with creat():
$ test -e /run/systemd/resolve/io.systemd.Resolve && echo exists
exists
$ bwrap \
--bind / / \
--bind /run/systemd/resolve/io.systemd.Resolve \
/run/systemd/resolve/io.systemd.Resolve \
/bin/true
bwrap: Can't create file at /run/systemd/resolve/io.systemd.Resolve: No such device or address
Tolerate the file existing as any type that we will be able to mount
a non-directory onto.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I copied this from Flatpak, but Colin was concerned about the trust
implications of this third-party dependency, and it doesn't seem
particularly important.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're running on an operating system configuration where bwrap is
expected to work (unprivileged user namespace creation is allowed,
not in a chroot, not in a container, etc.), run with BWRAP_MUST_WORK=1.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we fail as a result of `set -x`, It's often not completely obvious
which command failed or how. Use a trap on ERR to show the command that
failed, and its exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If two mount namespaces can both see a directory, and we bind-mount a
non-directory into that directory, we have to create a non-directory
to mount it onto:
$ ls -l ~/tmp/mountpoint
ls: cannot access '/home/smcv/tmp/mountpoint': No such file or directory
$ bwrap --bind / / --bind /etc/os-release ~/tmp/mountpoint true
$ ls -l ~/tmp/mountpoint
-rw-rw-rw- 1 smcv smcv 0 Feb 16 10:27 /home/smcv/tmp/mountpoint
The mount point is currently created as an empty world-writable file,
but this doesn't seem like a least-astonishment thing to do.
Create it with read-only permissions instead, to make it clearer that
it's just a placeholder and prevent other users from filling it.
Resolves: https://github.com/containers/bubblewrap/issues/337
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are using a case-insensitive filesystem the bind-mount operation
might fail when `/proc/self/mountinfo` is checked.
In a case-insensitive filesystem, if we ask to mount a certain
directory, e.g. '/CI_fs/foo', the kernel might add its entry in
`mountinfo` as '/CI_fs/FOO'. This happens because the kernel populates
`mountinfo` with whatever case combination first appeared in the dcache.
With this patch we open the requested path and look at its
`/proc/self/fd`, using readlink(), to get the path case combination that
the kernel is also expected to be using.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
bubblewrap uses pkg-config to find e.g. the selinux libraries.
pkg-config itself is not looked for if the path for the bash
completions is given by command line.
this call makes sure that pkg-config is found either way.
downstream bug: https://bugs.gentoo.org/674312
Ironically, if running sudo root the path to test-bwrap may
be unreachable in the user namespace as root does not have
permission, and CAP_DAC_OVERRIDE only works for mapped uids.
Fix by using /proc/self/exe for nested bwrap.
`--bind /proc /proc` and `--unshare-all` results in `/proc` being
for the wrong pid namespace causing `namespace_ids_read` to fail,
either reading the wrong process dying with an error.
For example try: unshare -rpfm --mount-proc make check
There's an effort to migrate Linux filesystems to handle the y2038
problem, which is great. However, recently a kernel change landed
that emits a warning when mounting a filesystem that doesn't
handle it, and this notably shows up even when *remounting* e.g.
for a read-only bind mount:
Using e.g. `rpm-ostree install cowsay` there's a spam of:
```
[ 189.529594] xfs filesystem being remounted at /sysroot supports timestamps until 2038 (0x7fffffff)
```
Now particularly when creating a our bind mounts, let's
ask the kernel to be quiet about it. This is not a major event
worthy of a kernel log.
