On Tue, Jan 14, 2003 at 10:01:47PM -0600, Lee Eakin wrote: > 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.
Nope. The files-from contents needs to passed on stdin otherwise we would hit command-line length limits. That is why i'm stressing the fact that allowing paths not within the source or destination trees specified on the command-line would bypass your ssh command= wrapper restrictions. > > > > 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 -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html