strip setuid/setgid bits on backup (was Re: small security-related
erich at cac.washington.edu
Mon Jul 8 08:53:04 EST 2002
Hi, I'm new around here and thought I'd join the discussion. Hope that's
> I'm inclined to push for more flexibility with:
> Runs <exec_pathname> on the 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.
> Dan's patch would therefore be reduced to the single script:
> xargs chmod u-s
The post-process is more flexible but one issue I'm currently living with
is rsyncing millions of files. This solution would not be my first choice
if I wanted to flip a permission bit on each file. Spewing 10 million
filenames/dispositions into another script (especially the bad example of
xargs which would fork up a storm) is mildly inefficient when you move
into this scale. Especially for the case in question where a setuid bit
need be changed and rsync has already done a stat and is dealing with the
file and could easily do it immediately at much lower cost.
Not to mention, is it a real long-term goal is to redesign rsync to deal
with large numbers of files by not building the entire file list up front?
If rsync is ever rewritten work directory by directory (or whatever)
building small file lists instead of building the mega filelist then when
do you run the post-process script? After each small batch of files? Or
store up the disposition list till the end effectively building a huge
> This would also allow rsync users to post-process modified files in
> whatever way they wish.
I'm not an advocate for the original patch just weighing in on not liking
the post-process idea as currently described.
More information about the rsync