The article suggests to use rclone in order to serve a REST server through SSH and careful setting up of the SSH account to only allow it to call the rclone command. Then the append-only functionality is achieved through the rclone setting.
Would it work and be safe to simply set up a regular SFTP account for use of restic (without rclone in the picture at all), and then modify file rights on the repository server, in order to prevent deletion of replacement of files. For example a script could change all the files to be owned by root and only be readable by the restic user (the ssh user on that server which restic uses to log in). This would achieve the same effect? The only additional setting needed would be a simple script that would go through the repository and change file rights of all the new files as they are added?
Would this be as secure (against malicious client)?
Would it work at all, or would restic have some problems with all the files in its repository only readable but not writeable or deleteable, when using an simple SFTP backend?
There’s one problem with this: in order to add new files to the repo, you need write permissions on the directory which also allows deleting files, even if you can’t write to the file itself. This could be worked around though by either using file system attributes (
chattr +a $directory) or hard linking all files to a second directory tree which the client can’t access so that they can be restored if the client would delete them from the primary tree.
An easier way to achieve this is to use the sticky-bit on the directories, like in
/tmp/ (chmod +t /path/to/repo). That way, users with write permission (e.g. due to group membership) can still create new files, but only root, the directory owner, or the owner of the file can delete one.