Fix handling of Vulkan manifests in /etc (and also error handling)
- Feb 19, 2021
-
-
Simon McVittie authored
In the code path where we copy a file that would not otherwise be visible in the container, the copy doesn't actually work, because glnx_file_copy_at() opens regular files with O_NOFOLLOW and so refuses to read through the "magic symlink", failing with ELOOP. This can be reproduced by having a Vulkan ICD manifest in /etc/vulkan/icd.d/*.json whose `library_path` is just a SONAME. pressure-vessel tries to copy the file, and fails. It turns out glnx_file_copy_at() is not the right function here anyway, because it tries to fchown() the destination file to match the source file, which is going to work poorly if we are copying a file owned by root (which we often are). Just use the important part of it, which is glnx_regfile_copy_bytes(). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/366 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
_srt_resolve_in_sysroot raises a GError, so it's a bug to set the GError again. Just put an explanatory prefix on the error we already had. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Putting a prefix on the rather opaque error should make it more obvious what we were trying to do. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we pass in SRT_RESOLVE_FLAGS_READABLE or SRT_RESOLVE_FLAGS_DIRECTORY, and something goes wrong while we are opening the file, then the best diagnostics libglnx can give us will be something like "openat(/proc/self/fd/21): <strerror result>", which is not very informative. Adding current_path turns this into something more like "Unable to open "foo/bar": openat(/proc/self/fd/21): <strerror result>", which gives us more hope of figuring it out. I originally suspected this was the error path being hit in <https://github.com/ValveSoftware/steam-runtime/issues/366 >, but now I think it probably isn't. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-