Please pardon my butting in again. I am not a developer, but I am very
interested in this option because I've need it in the past and had to work
around the lack of it with include/exclude options (I wanted to sync only
a few files from a large directory, and needed it to work via the daemon
for anonymous access). I also maintain the perl wrapper File::Rsync so I
do my best to understand all of the options so I can handle them properly
in the perl module.
---begin quoted text---
> From: Wayne Davison <[EMAIL PROTECTED]>
> Date: Tue, 14 Jan 2003 19:39:49 -0800
>
> On Tue, Jan 14, 2003 at 07:02:58PM -0800, jw schultz wrote:
> > Up till now rsync hasn't touched anything outside of the paths
> > specified on the command-line. Changing that would mean access to
> > rsync via ssh would no longer be restricted, just disabled.
>
> Are you saying that some people have special ssh scripts that check
> and/or tweak the file names on the command-line to ensure they fall with
> certain bounds when running rsync commands? I.e., if someone ran this
> command:
>
> rsync -av -e ssh "source:dir /foo/two /bar/three" /tmp
>
> the remote ssh setup would handle the presence of the extra "/foo/two",
> "/bar/three" args? If so, I hadn't realized that people were limiting
> ssh access by more than the traditional user/group/permissions access.
>
Yes, people do restrict args via ssh key restrictions. I have done this
myself on many occasions. The environment variable SSH_ORIGINAL_COMMAND
is passed to the actual command called from the command= key option so I
write a small script to parse thru the variable checking each arg making
sure they are what I expect (and possibly modifying them). I also check
pathnames to make sure they all fit my restrictions. I then either exec
rsync, or email the offending command to root if I find an exception
(the mail also makes debugging easier).
I assume the remote end will get the expanded contents of files-from so
ssh command parsing would still work properly.
> > Sanitizing the paths to force them to be relative on pulls
> > but not pushes would be too asymetrical for my liking.
>
> I agree that if we find that we want to sanitize the paths in some cases
> that we should just make it the default for files-from -- i.e. make it
> where nothing can get beyond the root dir specified on the command-line.
>
> > I'd rather just disallow or sanitize absolute paths.
If you try to pull a full pathname from a daemon 'rsync remote::/foo' it
errors out with:
ERROR: The remote path must start with a module name not a /
so any sanitize code could first make sure all pathnames begin with a valid
module and then make sure the file or dir is really inside that module.
---end quoted text---
--
Lee Eakin - [EMAIL PROTECTED] - Internet/Naming Services, Texas Instruments
LAWS OF COMPUTER PROGRAMMING:
II. Any given program costs more and takes longer.
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
