Prevent dereferenced path of symlinked directories from printing on client side log output

[Greg Deback (rsync)]

Hello,

I found something that could be interesting for you : the *command=""* that
you can put at the beginning of the corresponding line of your
$HOME/.ssh/authorized_keys. For this to work, you must use rsync with
rsa/dsa keys.
$HOME/.ssh/authorized_keys should have one line like this on the server
host :
command="rsync --server --sender -Phaz --copy-links --copy-dirlinks .
/backup/path/" ssh-rsa YourVeryLongSSHKey...
Note that this will override all options passed to rsync on the client side.
See this link :
http://learninginlinux.wordpress.com/2009/05/07/rsync-fixed-server-side-options/

Greg


On Tue, Dec 18, 2012 at 10:13 AM, wesley <wesley at tormail.org> wrote:

> I'm trying to figure out if there is some way to run an rsync daemon which
> makes a mix of "real" and symlinked folders available to a client such that
> all the folders appear as "real" to the client.
>
> I realize the --copy-links and --copy-dirlinks accomplish this when
> invoked from the client side (and that is currently how I am accomplishing
> this). Is there any way to essentially "force" those options from the
> daemon end? So that to a client, a symlinked dir will always appear as the
> referent dir.
>
> If not, then if at all possible, I would like to block the referent dir
> from showing up in the log output on the client side. If the client is
> printing --progress output to the terminal, or is tailing the log output,
> rsync will indicate when a directory is a symlink and print the
> dereferenced directory. Is there any way to prevent rsync from printing
> drreferenced directory info? Printing this info to the client can leak
> potentially sensitive information about the filesystem/usernames/etc on the
> server running rsyncd, which is part of the reason why symlinks are being
> used (to present a consistent "clean" set of read only dirs that may be
> downloaded from). Presenting the referent dir paths leaks information that
> it would be preferable not to leak.
>
> Thanks to anyone that can point me in the right direction (or letting me
> know if it's not possible). If it's not possible, would very much
> appreciate if it could be considered as a feature enhancement to the rsyncd
> because of the privacy implications of leaking referent path data to
> clients.
>
> --
> Wesley
>
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options: https://lists.samba.org/**
> mailman/listinfo/rsync <https://lists.samba.org/mailman/listinfo/rsync>
> Before posting, read: http://www.catb.org/~esr/faqs/**smart-questions.html<http://www.catb.org/~esr/faqs/smart-questions.html>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20121227/dbb6d3df/attachment.html>