Les Mikesell wrote at about 13:05:40 -0600 on Wednesday, February 10, 2021: > On Wed, Feb 10, 2021 at 12:47 PM Felix Wolters <li...@felix-wolters.com> > wrote: > > > > I may add, that working with a non-privieged user isn’t even necessary in > > many cases, as rrsync is able to restrict access to (1.) a specific > > command (if need be with specific options), (2.) a specific folder, and > > (3.) to read only access – but offer full root access and allowing rsync > > -a to keep users, groups and permissions. That makes it powerful. > > > > The problem here just seems to be that rrsync (on the client to back up) > > and rsync-bpc are not compatible, and a patched rrsync will – hopefully! – > > be the solution. > > Isn't rrsync just a perl wrapper to start rsync but ensure it is only > accessing a permitted subdirectory? If so it should be a matter of > tweaking the command to start it to be compatible.
Yes - I just looked it up... See: http://biplane.com.au/blog/?p=591 Basically it seems like rrsync doesn't do much more than use the ssh forced (restriced) command functionality, where the commands run by ssh are limited by adding "command=rrsync..." to the authorized keys file (which itself is bad as one should use the full path in the command). Based on this, the way to fix rrsync to be rsync-backuppc compatible is probably embedded in my previous note where in my sudoers file I have abstracted the exact rsync command and arguments that rsync-bpc invokes on the remote host. Indeed, I believe that my solution with sudo is likely better/more secure than rrsync for multiple reasons: 1. Rather than allowing root ssh and then restricting access to some commands, I only allow ssh to a non-root user and only elevate a specific command. This intuitively seems to be more secure than trying to handcuff a root login as my login user is never root. 2. Furthermore, if you have an ssh-agent or if you inadvertently change your authorized_keys file, you will expose full root capabilities while it is much less likely that you will inadvertently change your sudoer file to expand access. 3. In general, sudoer offers more fine-grained control over access as that is what it was designed and hardened to do -- while the rrsync approach relies on a generic and pretty blunt ssh feature. 4. Further, along that line, while sudoer has been well-tested, I'm not sure how well tested the perl rrsync code is for security and vulnerabilities in whatever libraries it may use. We all hopefully remember the past issues with trying to harden perl to allow sudo perl scripts. Vulnerabilities are possible in not just perl itself but in any library called by rrsync. 5. At the end of the day, with rrsync, you are still allowing root access to ssh and that just doesn't feel right. And a breach in security may be harder to distinguish as it shows up as a root user. In my approach, the only user that ever logs on to your remote host is a limited user -- which can easily be seen and logged -- and distinguished from a generic root user. Finally, while the sudoer code I shared in my previous note was just aimed at restricting the sudoer power to rsync with specific flags, I'm pretty sure that it could be easily expanded to also limit access to only certain files/directories but just extending the sudoer line to add the paths desired, thereby further restricting the reach of the sudo command allowed. Best of all my approach does not require adding and maintaining a new program (rrsync) along with the burden of installing perl on the remote host. Now all I need is Craig to tweak the construction of the $Conf{RsyncClientPath} variable so that I don't have to use an awful kluge to allow "/usr/bin/sudo /usr/bin/rsync" as the remote rsync command... Jeff _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
