[HN Gopher] Using rsync to create a limited ability to write rem...
       ___________________________________________________________________
        
       Using rsync to create a limited ability to write remote files
        
       Author : zdw
       Score  : 34 points
       Date   : 2024-09-05 04:48 UTC (3 days ago)
        
 (HTM) web link (utcc.utoronto.ca)
 (TXT) w3m dump (utcc.utoronto.ca)
        
       | evilDagmar wrote:
       | Absolutely. I have used the heck out of this on systems since I
       | found out about rrsync.pl and read through the code to make sure
       | it was using a solid approach.
       | 
       | With a quick keypair generation one can quickly deploy read-only
       | (and probably write-only although I've never tried that) access
       | to select parts of a filesystem and do selective near-line
       | backups of important files into a "history" host of sorts, and
       | even leverage rsync's ability to use hardlinks in place of files
       | that have not changed since the last run so no space is
       | needlessly wasted backing up 400 copies of the same thing.
       | 
       | It was wonderful that I didn't have to write such a wrapper
       | myself.
        
       | therein wrote:
       | Didn't know this existed, useful to know for sure.
       | 
       | I am guessing one would want to disable the Sftp subsystem for
       | SSH too.
        
       | rsync wrote:
       | There is a mistake that some people make when pointing simple
       | rsync jobs to us - they preserve ownership but send files owned
       | by root.
       | 
       | This actually works... They successfully back up their files to
       | their account with 0:0 ownership.
       | 
       | But, of course, they are not root on our end so they either lose
       | the ability to write or change the files... Or they lose the
       | ability to read them at all.
       | 
       | The easy solution is this neat rsync argument --fake-super ...
       | but I guess _you could make this mistake on purpose_ with
       | permissions that allowed read access to all ... and successfully
       | create write once, read, only backups...
        
         | jraph wrote:
         | > But, of course, they are not root on our end
         | 
         | Could this be made possible using something like user
         | namespaces / containers with their own hostnames?
        
       | Denvercoder9 wrote:
       | Instead of writing out "no-port-forwarding,no-X11-forwarding,no-
       | agent-forwarding,no-pty" in the authorized_keys file; you can use
       | the "restrict" keyword to enable all current and future
       | restrictions.
        
       ___________________________________________________________________
       (page generated 2024-09-08 23:01 UTC)