On Tue, Jan 14, 2003 at 07:39:49PM -0800, Wayne Davison wrote: > 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.
I don't know if they can handle correctly multiple source paths on the command line but there are certainly people using the command= option in authorized_keys to invoke special scripts to check and/or tweak the rsync command line restrict rsync to pre-aproved paths. > > 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. > > Note that it's more pervasive than just absolute paths, since someone > can use args like "../../../etc/password" or "good_dir/../../bad_dir" > (all of which the sanitize_path() call handles). Yes, the relative ../../... paths slipped my mind but that is a concern as well. I'm aware that restricting --files-from to having relative paths is somewhat limiting but i think it may be the better approach. You can always do rsync --files-from=list / remote:/ If you need to. I haven't had time yet to closely examine or try it but i have two questions: with the -r or -a options does this recourse on directories in the --files-from list? What happens when there are implied directories that are missing on the destination? For example rsync -a --files-from=list src dest with the list having foo/bar/one will dest/foo and dest/foo/bar be created with the source directory attributes if they don't exist; will it fail; or will the missing implied directories be created with umask perms? -- ________________________________________________________________ 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