strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

[Dave Dykstra]

The idea of the rsync client executing programs has been descussed before
and rejected because it could easily be done by an external program if
rsync simply passes it filenames.  The only case I can see for having rsync
execute programs is in the daemon; that was once approved in principle but
nobody every implemented it.

What we need, have long wanted, and even once had someone volunteer for
(but it was never completed), is a major upgrade to the --log-format option
to allow a lot more flexibility in what gets printed, and to have it work
consistently with and without --dry-run.  This would work too with lots of
files because the names get streamed out as they're processed.  See for
example the thread around
    http://lists.samba.org/pipermail/rsync/1999-January/000954.html

That would be better than the suggested patch to strip off setuid/setgid
from backed up files and the addition of the -s option.

- Dave Dykstra


On Mon, Jul 08, 2002 at 03:52:16AM -0700, jw schultz wrote:
> On Mon, Jul 08, 2002 at 06:01:48PM +0800, Adrian Ho wrote:
> > On Mon, Jul 08, 2002 at 05:37:13PM +0800, Adrian Ho wrote:
> > > I'm inclined to push for more flexibility with:
> > 
> > Actually, make that:
> > 
> >   --post-send=<exec_pathname>
> >   --post-recv=<exec_pathname>
> >     Runs <exec_pathname> on the sender/receiver just before rsync exits.
> >     <exec_pathname> is passed a list of fully-qualified pathnames on
> >     stdin (one per line) that have been created, modified or deleted by
> >     this rsync instance.
> > 
> > - Adrian
> > 
> 
> I like this more general post-processing approach.  It would
> allow much more flexibility without adding lots of other
> options (and bloat) and fits with the UNIX philosophy.
> 
> However, if it lists created, modified and deleted files it
> will need to differentiate.  It should instead list the files
> and the action.  If action is unbroken by whitespace it
> can then be parsed easily.  Also the path should not be
> fully qualified but instead should match that of the
> commandline with cwd the same as the rsync launch.
> 
> <example>
> UPDATE	foo/
> CREATE	foo/bar1
> UPDATE	foo/oldie
> DELETE	foo/gonzo
> HLINK	foo/gorgon
> SLINK	foo/plank
> SPECIAL	foo/sock1
> </example>
> 
> This example has the action first so that it is both easily
> seen and parsed even if the filenames contain spaces.  The
> tab is because that is the default for cut and almost
> everything else copes with tabs either by default or as the
> equivalent of spaces.
> 
> In this way the post-process script example given earlier
> would be something like:
> 
> grep -v '^DELETE'|cut -f2-|xargs -ri chmod ug-s \"{}\"
> 
> Unlike the previous example this wouldn't emit hundreds of
> error messages about deleted files.  Some other uses might
> care about the deletes though.
> 
> For some uses this output would actually be an improvement
> on the logging so it might be nice to be able to direct it
> into a file without spawning a process.