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

jw schultz jw at
Mon Jul 8 03:53:01 EST 2002

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.

CREATE	foo/bar1
UPDATE	foo/oldie
DELETE	foo/gonzo
HLINK	foo/gorgon
SLINK	foo/plank
SPECIAL	foo/sock1

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.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list