Reliably mount input files

[apyrgio]

The Dangerzone container runs with the same UID/GID (--userns=keep-id) as the user that runs the Dangerzone application in the host. However, this does not mean that the container can always read the files that the user can, mainly for two reasons:

1. A file may belong to a different group:

   The file may be accessible to the user outside the container solely because the user belongs to the same Unix group as the file. We already have error reports for that (Permission denied: container can't write to /dangerzone #157). The underlying cause for this error is that Podman does not pass supplemental group information to the container by default. For more info, read this Red Had article.

2. An SELinux policy may block access:

   The file may have an SELinux label that does not match the container's. See this Red Hat article for more details. This issue has also been reported by our users (Permission denied: container can't write to /dangerzone #157 (comment)).

A solution to the above can be the following:

• Copy the file into a temporary directory. The copied file will then have the same UID as the user in the Dangerzone container, which is what we want. The alternative approach, leaking the user groups in the container, is not desirable, because other groups (like sudoers) could also leak
• Label the copied file with the proper SELinux label (:Z). It's important that we change the SELinux label in the copied file, else the original file would become inaccessible even from the host.

[apyrgio]

I don't like it, but I have to live with the idea that this feature will not have CI tests, at least for now. There are two reasons for that:

1. Testing case 1, i.e., file accessible only to a supplemental groups requires the following:

   • A second user that will own the file, and root permissions to change the owner.
   • A second group that will own the file, and adding the user that runs the tests to the new group. This must be done before the test process starts, so that it inherits this group.
   • Read permissions for the group, no permissions for others, and root permissions to do that.

   Implementing the above is not worth it, since we will soon merge WIP: Implement Linux User Namespaces support #248, which will remove the --userns=keep-id flag, and thus all this logic.

2. Testing case 2, i.e., mismatching SELinux label, requires an SELinux capable host system, and probably root permissions (haven't tried it actually). Again, this complexity is not worth it for a :Z mount argument.