Restricted ssh commands compatibility (rrsync)

[cytopia]

Restricted ssh commands compatibility (rrsync)

[cytopia]

Now the backup seems to complete successfully.

This is because there is no dir check on an existing directory. Try to play around with edge cases, where the directory does not exist, or is a file or a symlink, etc.

Besides, a little bit later down the lines, there is also a test -L check required for incremental backups. I guess this might also be an issue on your side.

The test command currently works well and keeps the source simple. I honestly don't see a way of replacing them. Feel free though to make suggestions and always keep edge cases in mind.

On the other hand, why don't you just allow the test command as well?

[Jip-Hop]

keeps the source simple

One of the great things about linux-timemachine :)

If I were to allow the test command, users could probe for files outside their restricted directory. Besides, test alongside rrsync would require writing a wrapper script.

The test -L check would be an issue if my destination is accessed via SSH. But I'm only using my SSH server as source (made it read-only with rrsync). So that's not a problem in this case.

I was thinking maybe instead of test something like this:

if [[ $(rsync "${directory}" . --dry-run 2>/dev/null) == "skipping directory"* ]];then echo "It is a directory"; fi

Tested with a file, directory, symlink and nonexistent file.

I know it's ugly, but does not require another command besides rsync and works with rrsync xD

[cytopia]

If I were to allow the test command, users could probe for files outside their restricted directory.

Isn't that something you could do with a shell anyways?

if [ -f ./some_file ]; then echo "some_file exists"; fi

[cytopia]

You can also use the sed command (also used in the script) to probe for files: Nvm, sed is only run locally

> sed -i'' 's///' file
sed: -e expression #1, char 0: no previous regular expression

> sed -i'' 's///' fileno
sed: can't read fileno: No such file or directory

[Jip-Hop]

Isn't that something you could do with a shell anyways?

Yes, but my plan was to block shell access and only allow rrsync over SSH. So users won't be able to run the commands you suggested (which is good) and can't probe or access files outside of their restricted directory.

However then they also won't be able to run the test command and linux-timemachine won't work.

So that's why I suggested to not rely on test, or find a way to replace test with an rsync command (which rrsync would allow).

For the time being I'm chrooting SSH users to their home directory, so they can't use rsync at all...