This release includes a series of bugfixes and important packaging
improvements that were found to be necessary while preparing for making
libpathrs a default dependency of runc.
Added
- New
EXTRA_RUSTC_FLAGSandEXTRA_CARGO_FLAGSvariables have been added to
ourMakefile, making it easier for packaging tools to adjust builds while
still usingmake release. install.shnow accepts--rust-targetand--rust-buildmodeas parameters
to make cross-compilation workflows easier to write (in particular, this is
needed for runc's release scripts).- We now produce signed release artefacts for our releases (though currently
only in the form of signed source andcargo vendortarballs). The accepted
set of signing keys are available inlibpathrs.keyring.
Changed
- The
O_PATHresolver forprocfsnow has an additional bit of hardening
(each component must be on a procfs -- previously we would check that it is
on the same mount, which is an even stronger requirement but on older kernels
it is possible to not have a mount ID to check against).
Fixed
-
Previously,
staticlibbuilds of libpathrs (i.e.,libpathrs.a)
inadvertently included symbol versioned symbols (@@LIBPATHRS_X.Y), which
would cause linker errors when trying to compile programs statically against
libpathrs.This has been resolved, but downstream users who build runc without using
make releasewill need to take care to ensure they correctly set the
LIBPATHRS_CAPI_BUILDMODEenvironment variable when building and build
libpathrs.aandlibpathrs.soin separatecargo build(orcargo rustc) invocations. This is mostly necessary due to the lack of support for
#[cfg(crate_type)]. -
go-pathrsnow correctly builds on 32-bit architectures. -
When doing
procfsoperations, previously libpathrs would internally keep a
handle toProcfsBaseopen during the entire operation (due toDrop
semantics in Rust) rather than closing the file descriptor as quickly as
possible. The file descriptor would be closed soon afterwards (and thus was
not a leak) but tools that search for file descriptor leaks (such as runc's
test suite) could incorrectly classify this as a leak. We now close this
ProcfsBasehandle far more aggressively. -
RHEL 8 kernels have backports of the fd-based mount API (
fsopen(2),
open_tree(2), et al.) but somerunctesting found that they have very bad
(and very difficult to debug) performance issues. Thus, to avoid broken
backports libpathrs will now explicitly refuse to use the fd-based mount API
if the reported kernel version is pre-5.2 and will instead fallback to the
less-secureopen("/proc"). -
libpathrs 0.2.0 added some
fdinfo-based hardening to the procfs
resolver whenopenat2is not available. Unfortunately, one aspect of this
hardening had a hard requirement on a kernel feature only added in Linux
5.14 (namely theinofield infdinfo) and thus
inadvertently increased our minimum kernel version requirement quite
significantly. This additional hardening is now only treated as mandatory if
the host kernel version is Linux 5.14 or newer. -
Some of the same
fdinfo-based hardening had a separate issue when running
in the context of a non-dumpable process on pre-5.14 kernels -- causing
spuriousEACCESerrors. We now permitfdinfoto be inaccessible in this
very specific situation.