Allow unsafe characters if invoked as qubes.UnsafeFileCopy #497
Conversation
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
ed6aa8c to
95a30dd
Compare
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
95a30dd to
9d625db
Compare
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024061618-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024052808-4.3&flavor=update
Failed tests12 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/101100#dependencies 39 fixed
Unstable tests
|
There was a problem hiding this comment.
This PR is missing actually introducing qubes.UnsafeFilecopy service. And also changing qvm-copy to choose service based on files to be copied (see QubesOS/qubes-issues#8332 (comment))
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
9d625db to
a95d3e9
Compare
Fixes a compiler warning.
Previously various invalid arguments were silently ignored or misparsed.
According to the manual page, setfsuid() does not provide any indication of success or failure. The only way to check if it succeeded is to call it again with -1 as the UID and check the return value.
This should never happen.
No functional change.
There is no good reason not to use these flags.
This requires QubesOS/qubes-linux-utils#113. It also adds a new argument parser based on getopt_long(), which is used instead of the old hand-rolled code unless there are at least two arguments and the first one starts with an ASCII digit. Part of QubesOS/qubes-issues#8332
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
414ea02 to
bf08a35
Compare
|
This fails to build on Debian: Likely a missing Build-Depends: |
|
In fact it fails to build on Fedora too, due to a different reason: |
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
bf08a35 to
abdc869
Compare
|
Build failed because QubesOS/qubes-linux-utils#113 is not part of the latest released package. |
The logs I pasted were from a pipeline that included that PR too. But yes, this PR alone is expected to fail. |
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
a1940e4 to
cf63b3e
Compare
I checked and this version builds with QubesOS/qubes-linux-utils#113. |
|
qvm-copy tests fail (see updated openqa report above), example failure: |
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
cf63b3e to
3b6cef5
Compare
|
This is due to an outdated check from when I misunderstood how |
|
Manual test passed. |
|
I will update the code to use the service argument. |
This is done by means of the --allow-unsafe-characters flag to qfile-unpacker, and is only done if allow-unsafe-characters is passed as a service argument. The service argument is always visible in the qrexec prompt, so users will know if this flag will be used and can choose to reject the call.
This adds a filesystem tree checker that determins if a directory tree can be copied with qubes.Filecopy or if qubes.UnsafeFileCopy is required. It also produces the total size of the tree, which qfile-agent uses for progress reporting. The checker can also be used for other purposes, such as checking if there are nasty characters or symbolic links in a filesystem tree unpacked via a command such as 'tar'.
This makes testing much, *much* easier. The binaries use an rpath to find the libraries they depend on, and qfile-copy uses $0 to find the binaries it uses. /usr/bin/qfile-unpacker needs a different rpath than the binaries under /usr/lib/qubes, so they must now be built separately (from the same object files).
DemiMarie
force-pushed
the
less-safe-unpack
branch
from
3b6cef5 to
ef3f478
Compare
This uses QREXEC_SERVICE_FULL_NAME to detect what the service was invoked as. Non-empty arguments are reserved for future use.
This requires QubesOS/qubes-linux-utils#113.
Part of QubesOS/qubes-issues#8332