--copy-unsafe-links fix checked in

[Dave Dykstra]

On Wed, Jan 15, 2003 at 02:24:10PM -0800, jw schultz wrote:
> On Wed, Jan 15, 2003 at 10:27:31AM -0600, Dave Dykstra wrote:
> > In my research into this I also found that 2-1/2 years ago somebody
> > posted a patch that included a fix for this buried in it, and that I
> > had promised to integrate his patch but I never did it, I think due to
> > various other crises that were happening at the time.  I also don't think
> > I realized that the existing option was broken.  His patch expanded the
> > --copy-unsafe-links option so that unsafe symlinks on the destination
> > side are also followed.  I'm sure that could be a useful option, allowing
> > things like moving some parts of a directory structure on the destination
> > side to a separate filesystem.  However, it really doesn't have anything
> > to do with the name "copy-unsafe-links".  I'm thinking that either I
> > should rename the --copy-unsafe-links option to --follow-unsafe-links
> > and add this functionality, or add a separate option by that name that
> > only affects the destination side.  Does anybody have an opinion on those?
> 
> By follow-unsafe-links do you mean that if it finds a
> link to a directory it will follow that link and descend
> that directory tree located outside the tree being rsynced?
> That is what i would infer following to do.  While
> potentially useful this is also potentially dangerous.
> Following directory links should, if added, be distinguished
> from I/O through file links.
> 
> Even if it is just links to files that it would write
> through it should be a separate option.  It is one thing to
> read through an unsafe link, quite another to write through it.
> A distinction should be made between them.
> 
> There is a reason why apache disables following links by default.
> 
> I may be reading you incorrectly but the ideas presented
> would, i think, need four options for "unsafe" links.
> I have made up names for the other three for the sake of
> enumeration.
> 
> 	--copy-unsafe-links	read through to files
> 	--write-unsafe-links	write through to files
> 
> 	--follow-src-links	descend directory links on src
> 	--follow-dest-links	descend directory links on dest


I certainly wouldn't want to have 4 options, it's confusing enough as
it is.  Rsync never overwrites files, it just replaces them, so at a
minimum I don't think --write-unsafe-links would be of value.  I don't
think it's worth distinguishing between files and directories on the
source side because I don't think that descending into a directory link
on the source side has much risk associated with it.

You have at least persuaded me to not have copy-unsafe-links affect
the destination.  I think I'll probably just drop the whole idea.  I had
briefly considered the problem of somebody malicious first copying in a
symlink to an external directory and then copying again to recurse into
it, but I dismissed it because I figure that pretty much the only time
time rsync users need to worry about malicious use is when uploading to
an rsync daemon module, and that's already protected by either chroot
or sanitize_path.  I had not considered the problem of accidental damage
that could be done, however, and for that I think it's better to not have
the option.

- Dave Dykstra