[Pulp-dev] Proposal: Changing in 3.1 that Artifact.save() will hard-link/copy, not move

Simon Baatz gmbnomis at gmail.com
Wed Jan 8 17:02:32 UTC 2020


On Tue, Jan 07, 2020 at 04:45:54PM -0500, Brian Bouterse wrote:
>    We had two bugs filed recently [0][1] which suggest that when using the
>    default backend for Pulp, i.e. pulpcore.app.models.storage.FileSystem
>    Pulp should not be "moving" files. This is the default behavior Django
>    gives us, and it destroys data when sync'ed from file:/// for example
>    [1].

I am surprised that file:/// should be supported at all. This means
that a worker process must be able to access basically any file on the
system. Is this covered by the (upcoming?) SELinux policy? I would
expect workers to be more constrained than that. Or do we expect
the user to label files before importing?

>    I propose that with 3.1 we fix this bug by switching
>    pulpcore.app.models.storage.FileSystem to leave files in place and
>    either hard-link (same filesystem) or copy (different filesystem).

We should not use hard links:

- On systems with sysctl "fs.protected_hardlinks" enabled (Ubuntu, Fedora),
  the files would have to be owned by the pulp user to be able to
  create hard-links at all.
- On systems with SELinux enabled, these hard links will share
  the labels.
- Imported hard links are not protected against modification of the
  original file.

We could try to reflink the file and fall-back to copy (like "cp
--reflink=auto" does)





More information about the Pulp-dev mailing list