Rsync files from remote host to local host failed with "No such file or directory"

snap
1

Hello folks, I was trying to use the rsync snap to copy files between a local Ubuntu server and a remote UC22 RaspberryPi Ubuntu Core system.

With the rsync snap installed in devmode on the remote Ubuntu Core system, I can copy files from the local Ubuntu server to it without any problem.

However I was unable to copy files back from the remote Ubuntu Core system, it will fail with No such file or directory:

$ rsync -ar -e "ssh $SSH_OPTIONS" $SUT_IP:/tmp/testfile ./
rsync: link_stat "/tmp/testfile" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1675) [Receiver=3.1.2]
rsync: [Receiver] write error: Broken pipe (32)

But the file exists on the remote Ubuntu Core system:

$ ssh $SSH_OPTIONS $SUT_IP ls /tmp
snap-private-tmp
systemd-private-59022ef600d244948e234cfbce15458c-systemd-logind.service-BLd0q7
systemd-private-59022ef600d244948e234cfbce15458c-systemd-resolved.service-7Cw1MF
systemd-private-59022ef600d244948e234cfbce15458c-systemd-timesyncd.service-14O6Sz
testfile

Has anyone tried this before?

Here is the information of the installed rsync snap:

$ snap info rsync
name:      rsync
summary:   Copying and synchronizing files and directories in Linux/Unix systems.
publisher: Sergio Cazzolato (cachio)
store-url: https://snapcraft.io/rsync
license:   unset
description: |
  Rsync (Remote Sync) is a most commonly used command for copying and synchronizing files and
  directories remotely as well as locally in Linux/Unix systems.
commands:
  - rsync
snap-id:      607xTofvb8vNMNr2aVjLxnTsooMOwZQU
tracking:     latest/stable
refresh-date: today at 07:54 UTC
channels:
  latest/stable:    1.0.0 2018-05-16 (12) 344kB -
  latest/candidate: 1.0.0 2018-05-16 (12) 344kB -
  latest/beta:      1.0.0 2018-05-16 (12) 344kB -
  latest/edge:      1.0.0 2018-05-16 (12) 344kB -
installed:          1.0.0            (12) 344kB devmode

Thanks!

2

Snaps have a private /tmp directory and have no access to the actual /tmp as seen on the host. This is motivated by the fact that /tmp may often contain data/files one would not like to share by accident with untrusted programs.

1 Like
3

:skull:

Unless I’m mistaken, this snap is six years old, and contains a binary of rsync that was released a decade ago? The source repo doesn’t exist, and it’s using the ‘official’ name.

$ snap download rsync
Fetching snap "rsync"
Fetching assertions for "rsync"
Install the snap with:
   snap ack rsync_9.assert
   snap install rsync_9.snap
$ unsquashfs rsync_9.snap
Parallel unsquashfs: Using 16 processors
41 inodes (42 blocks) to write

[================================|] 83/83 100%

created 39 files
created 29 directories
created 2 symlinks
created 0 devices
created 0 fifos
created 0 sockets
created 0 hardlinks
 $ grep rsync squashfs-root/snap/manifest.yaml  | tail -n 3
  rsync:
    - rsync=3.1.1-3ubuntu1.2
  build_url: https://launchpad.net/~sergio-j-cazzolato/+snap/rsync/+build/221349

Which may contain security issues?

syft scan -q file:olde-rsync.tar  -o syft-json | grype | grep rsync
NAME                INSTALLED                     FIXED-IN          TYPE  VULNERABILITY   SEVERITY
rsync               3.1.1-3ubuntu1.2              (won't fix)       deb   CVE-2023-45853  Medium
rsync               3.1.1-3ubuntu1.2              (won't fix)       deb   CVE-2022-42800  Medium
rsync               3.1.1-3ubuntu1.2              (won't fix)       deb   CVE-2022-37434  Medium
rsync               3.1.1-3ubuntu1.2              (won't fix)       deb   CVE-2022-29154  Medium
rsync               3.1.1-3ubuntu1.2              (won't fix)       deb   CVE-2018-25032  Medium
rsync               3.1.1-3ubuntu1.2              3.1.1-3ubuntu1.3  deb   CVE-2016-9843   Low
rsync               3.1.1-3ubuntu1.2              3.1.1-3ubuntu1.3  deb   CVE-2016-9842   Low
rsync               3.1.1-3ubuntu1.2              3.1.1-3ubuntu1.3  deb   CVE-2016-9841   Low
rsync               3.1.1-3ubuntu1.2              3.1.1-3ubuntu1.3  deb   CVE-2016-9840   Low

When can we get some kind of audit going on old snaps nobody appears to care about?

4

Ah that make sense, I will try use scp in this case. Thanks for the pointer!

5

Given that the snap is from 2018 and is owned by @cachio I would say it came to be in the early days of snapd with the idea of using it for testing. These days we have a bunch of test-snapd-rsync-* snaps which are owned by test-snaps-canonical account.

Maybe @Snapcrafters would we willing to take over the rsync snap?

1 Like