You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During payload processing, if we encounter a file entry corresponding to
the prefix directory itself, instead of referring to it relative to its
parent directory's file descriptor, we pass the absolute / path to the
*at() calls which then makes them fall back to path-based operation.
This isn't a huge problem as long as we're installing into the real root
prefix, however if the package is built as relocatable and the prefix is
overridden, we still operate on the real "/" instead of the new prefix.
This is wrong and even causes an installation failure if the relocatable
package is installed as a regular user who doesn't have write access for
the real root.
Fix this by simply passing "." instead of "/" to these *at() calls, to
always ensure fd-based operation.
However, this alone isn't sufficient since we can't delete the relocated
prefix directory itself this way when removing the package. This is due
to the fact that unlinkat(2) with AT_REMOVEDIR actually does a rmdir(2),
and that fails with EINVAL if called with the "." path.
Therefore, when removing a package and encountering the prefix directory
itself, stop the traversal in ensureDir() one level higher than usual so
that we refer to the prefix directory relative to its parent directory
via normal fd-based operation.
Lastly, don't even attempt to remove the prefix if it's *not* relocated.
This is safer and also gets rid of a spurious warning that's printed
when removing a non-relocatable package owning / as the root user.
Such packages (that include the sole / in their %files section) perhaps
aren't exactly common and those that exist aren't normally installed or
uninstalled on a production system (such as the "filesystem" package on
Fedora), however it's apparently used as a shorthand for including all
files in a relocatable package, as evidenced by TBD.
Either way, this is a regression introduced by the fsm rework addressing
the symlink CVEs (see rpm-software-management#1919 for details).
Fixes: TBD
0 commit comments