I have come across this issue on CentOS 8. However I think the check that that the download path is valid because if dnf reposync can write outside the download path then it might result in files being places they shouldn't be written to and a malicious or hacked repo might even be able to compromise the mirroring server. It would be nice to be able to strip out the ../ parts of the rpm path but that would mean that --download-metadata would result in metadata that didn't match the mirrored contents. Perhaps a safe_write_path option would work (defaulting to the download_path) so a server owner could allow writing outside the download_path in controlled situations.

We do need to keep the check in place. It was implemented as part of fix for CVE-2018-10897 (see https://access.redhat.com/security/cve/cve-2018-10897).

But on the other hand we are also aware of those repositories that use relative parent paths, which reposync currently cannot handle.

Based on the comment#2 I've implemented this small patch https://github.com/rpm-software-management/dnf-plugins-core/pull/441
What it basically does is:

- it separates --download-path (path where repository is downloaded to) and --safe-write-path (filesystem path where reposync is allowed to write)
- safe_write_path defaults to repository download path
- currently the --safe-write-path can be used only for syncing a single repository (must be used together with --repoid=<repoid>). I'm not sure this is needed but the intention was to make user think about directories where particular repository needs access.
- the PR also clarifies the error message printed in case reposync is trying to write into forbidden locations. The package name and package location as written in repository metadata were added to this message.

Let's say we have `dummy` repository which contains this package in its primary.xml:

<package type="rpm">
  <name>foo</name>
  <arch>x86_64</arch>
  <version epoch="0" ver="1.0.1" rel="0"/>
  <location href="../pool/foo-1.0.1-0.x86_64.rpm"/>
</package>

To synchronize this repo user needs to specify, that reposync needs write access also to the parent directory of download path:

$ dnf reposync --repoid=dummy --norepopath --download-path=/tmp/synced-repositories/dummy --safe-write-path=/tmp/synced-repositories

Without --safe-write-path reposync produces an error:

$ dnf reposync --repoid=dummy --norepopath --download-path=/tmp/synced-repositories/dummy
Error: Download target '/tmp/synced-repositories/pool/foo-1.0.1-0.x86_64.rpm' for location '../pool/foo-1.0.1-0.x86_64.rpm' of 'foo' package is outside of safe write path '/tmp/synced-repositories/dummy/'.

Any comments either here or in the pull request are appreciated.

Looks like a safe approach

I've tested this and it appears to work as expected and resolve the issue in what I believe to be a safe manner.  I would be in favor of going forward with this solution, ideally sooner rather than later so that we aren't using manually patched code.

I've also just submitted https://github.com/rpm-software-management/dnf-plugins-core/pull/457 that lets you make a more functional mirror of Amazon Linux style repositories. Would love some feedback!

(In reply to Stewart Smith from comment #9)
> I've also just submitted
> https://github.com/rpm-software-management/dnf-plugins-core/pull/457 that
> lets you make a more functional mirror of Amazon Linux style repositories.
> Would love some feedback!

this works! and would be nice to add to the official rpm too!

Thanks for testing it out!

I'm hoping to get some review / merge of the above PR before I back-port it into Amazon Linux 2022. I'm sure some user feedback on the functionality on it on GitHub could be appreciated.

Is it possible to get a RHEL8 test RPM package python3-dnf-plugins-core with the enhancemenced script /usr/lib/python3.6/site-packages/dnf-plugins/reposync.py ?

https://github.com/rpm-software-management/dnf-plugins-core/pull/481 is a PR from my colleague that implements what was discussed elsewhere as a good first step that increased assurance of not re-introducing a path traversal bug: a simple flattening of the directory structure.

The patch is merged, therefore moving it to post.

Due to security concerns related to the possible reintroduction of CVE-2018-10897 (see https://access.redhat.com/security/cve/cve-2018-10897), this Request for Feature Enhancement will not be delivered within the Red Hat Enterprise Linux release and this RFE is being closed as WONTFIX.

End users that wish to make use of the Unsupported "--safe-write-path" option are free to utilize the community solution merged in the MR below:

    https://github.com/rpm-software-management/dnf-plugins-core/pull/441

A build which includes the above is available via the following unsupported COPR build as well:

    https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/

Please note that the above falls outside the scope of the posted Service Level Agreements and supported procedures. It is provided as-is and no support is extended or implied.