--exclude-from works but "exclude from" in rsyncd.conf doesn't ?

[jw schultz]

On Sat, May 10, 2003 at 03:49:10AM -0700, Wayne Davison wrote:
> On Sat, May 10, 2003 at 02:18:02AM -0700, jw schultz wrote:
> > You seem to be talking about server-side "exclude" /a/ with a
> > command-line location of "server::module/a/b/c" where the whole
> > location should be barred.
> 
> Yes.  In this case the recursion code never even checks the /a/ dir
> since it started scanning down in /a/b/.  I've just fixed this to work
> without the extra "- /kludge/**" lines my previous patch required.
> It's named the same as before:
> 
>     http://www.blorf.net/rsync-daemon-exclude.patch
> 
> The fix I chose was to weed out excluded args by matching them a subdir
> at a time against the exclude patterns.  The result seems to work great.
> 
> > I'm also concerned about a server-side specified "exclude /a/b/c/d/e"
> > with a command-line location "server::module/a/b/c".
> 
> That was fixed in my first patch.  The fix I chose is to expand all
> config-specified values to a fully-qualified path, and to extend the
> matching code to prefix relative names with the current directory when
> it is compared against these absolute-path match values.  My latest
> patch is slightly better than the first one in that it should handle
> chroot mode now (though I haven't yet tested that to be sure).

Terif! At least we will close the hole.

Just to check, the absolute-path stuff doesn't allow path
components outside of the module to be reported in any
diagnostic/verbose messages, yes?  People likely to be using
this function may be that paranoid.

> > So far as i can see the lists are not independent.  For downloads the
> > client-supplied list seems to be appended to the list from the
> > rsyncd.conf file.
> 
> Oh yeah, I see what you mean now.  If the server list does an include of
> a filename, then the user's exclude of the filename would be ignored in
> the appended list.  Drat.  This is even more broken than I thought.

I'm not entirely sure i'm looking in the right place but at
least as an example, looking at check_exclude_file() in
flist.c

        if (check_exclude(fname, local_exclude_list, st)) {
                return 1;
        }
would be preceeded or followed by
        if (server_exclude_list && check_exclude(fname, server_exclude_list, st)) {
                return 1;
        }

so a file would have to not be excluded by either list to
pass.

Of course this only deals with downloads.  Upload exclusion
probably needs to be in generator.c.  Having the server-side
patterns in a seperate list will make conditionalising the
tests clean.


> > > Uploads are currently unaffected by the server-side {ex,in}clude
> > > restrictions.  I'm planning to look into fixing that as well.
> > 
> > It looks like a lot of work to get right.
> 
> Yeah, looks to be that way.  I think my current patch is a step in the
> right direction since it at least plugs the huge, gaping hole in the
> exclude list when the server tries to weed out subdirs in a directory
> tree.  If the rest proves too complicated, we should at least commit a
> fix for this problem (once it has been tested and approved).

You know this part of the code much better than i.  Hey, i
don't even use rsyncd; just ssh and occasionally local.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt