Issue with rsync deleting ACL-restricted subdirectory

[stratself]

Hi, I'm using SFTPGo for my homelab. I found that restricting subdirectories via ACLs do not work with rsync, despite seemingly working with sftp. I'm not sure if this is intended or a potential bug, so I'm leaving it here if anyone could find out more.

Minimal reproduction attempt

With an instance that enables rsync:

podman run --rm \ 
    --name some-sftpgo \
    -p 8080:8080 \
    -p 2022:2022 \
    -e SFTPGO_SFTPD__ENABLED_SSH_COMMANDS=rsync \
    -d drakkan/sftpgo:alpine

And a set of users with the following ACLs:

• foo (outer dir user):
  • Permissions: list
  • Per directory permissions:
    • /example-dir/bar: list
    • /example-dir: list, download, upload, overwrite, create_dirs, delete
• bar (inner dir user):
  • Permissions: list
  • Per directory permissions:
    • /example-dir: blank (no permission)
    • /example-dir/bar: *

(both users share the same root directory (/tmp) on local disk)

Manipulating the /example-dir/bar/ dir should only be possible with the bar user:

rsync -rtvh -e "ssh -p 2022" test/ bar@localhost:/example-dir/bar
# (bar@localhost) Password:
# sending incremental file list
# example1.txt
# example2.png
# example3.mp4

rsync -rtvh -e "ssh -p 2022" test/ foo@localhost:/example-dir/bar
# (foo@localhost) Password:
# >> errors out and sees 'permission denied' in logs

However, user foo can still modify /example-dir/bar/ and its contents if they specify the outer dir as the remote destination in rsync. The commands below work to undo the commands above:

# 1. using rsync's --delete flag
rsync -rtvh --delete -e "ssh -p 2022" test/ foo@localhost:/example-dir/
# (foo@localhost) Password:
# sending incremental file list
# deleting bar/example3.mp4
# deleting bar/example2.png
# deleting bar/example1.txt
# deleting bar/
# ./
# example1.txt
# example2.png
# example3.mp4

# >> bar/* files should NOT be deleted

OR

# 2. Adding a `bar` directory (no trailing slash) with different content
rsync -rtvh -e "ssh -p 2022" bar foo@localhost:/example-dir/
# (foo@localhost) Password:
# sending incremental file list
# bar/
# bar/example4.pdf

# >> bar/example4.pdf should NOT be added

OR BOTH

rsync -rtvh --delete -e "ssh -p 2022" bar foo@localhost:/example-dir/
# (foo@localhost) Password:
# sending incremental file list
# deleting bar/example3.mp4
# deleting bar/example2.png
# deleting bar/example1.txt
# bar/
# bar/example4.pdf

The same could not be said for SFTP/SCP commands that I found to be similar:

sftp -P 2022 foo@localhost
# (foo@localhost) Password:
# Connected to localhost.
sftp> cd example-dir/
sftp> put -r bar/
# Uploading bar/ to /example-dir/bar
# Entering bar/
# dest open "/example-dir/bar/example4.pdf": Permission denied
# upload "bar/example4.pdf" to "/example-dir/bar/example4.pdf" failed
# remote setstat "/example-dir/bar": Permission denied

scp -r -P  2022 bar/ foo@localhost:/example-dir
# (foo@localhost) Password:
# scp: dest open "/example-dir/bar/example4.pdf": Permission denied
# scp: upload "bar/example4.pdf" to "/example-dir/bar/example4.pdf" failed
# scp: remote setstat "/example-dir/bar": Permission denied
# scp: failed to upload directory bar to /example-dir

---

I've read the docs on system commands, but I couldn't still determine if this rsync supports falls into the intended behaviour or not. Do outer directories overrides the permissions set in subdirs? Or could this be some kind of permissions problem? As tested on a different setup, I believe this can be reproduced with groups ACLs instead of users', as well as with/without virtual folders being mounted as the /example-dir.

For now, I'll probably use separate directories for separate users for certainty. Thanks in advance for any help and clarification.

[drakkan]

rsync is an external command, and as such, its behavior is outside of our control. For this reason, we are likely to remove support for rsync in the next major release. In hindsight, adding support for it was a mistake.

[drakkan]

Please try using the latest development version. I think this change may help.

The main difference between rsync and scp is that scp is implemented directly within SFTPGo, giving us full control over its behavior. In contrast, rsync is executed as an external command, which means we have no insight into or control over what it actually does. From a security perspective, this is far from ideal and it's the primary reason I’d like to remove support for external commands altogether. rsync is currently the last one still supported.

To be clear, there's nothing inherently wrong with rsync itself. However, if we were to support it properly within SFTPGo, we would need to implement the low-level protocol internally rather than relying on launching an external process. Personally, I have no interest in developing native support for the rsync protocol, especially since there are many alternatives that use the SFTP protocol, such as rclone. That said, if someone from the community is interested in contributing proper rsync protocol support, I’d be happy to review and accept the contribution.

I'm still undecided about removing rsync support in the next release. I believe it's the right long-term decision, but I’m not sure how many real-world use cases this change might disrupt.

[stratself]

Hey, thanks for the reply and sorry that I didn't update the issue.

I actually switched to rclone, as per documentation suggestion. For it, syncing will soft-fail on permission-denied subdirectories (it still sync the rest, but reports an error). For perspectives, my use case is to sync files to a website's root directory, but not users subdirs at /~username/. Switching was as simple as rewriting a few lines of CI/CD code.

I believe this means I wouldn't be too affected with rsync support. I'd be okay with the decision to drop it as necessary