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

[jw schultz]

On Sat, May 10, 2003 at 01:17:35AM -0700, Wayne Davison wrote:
> On Fri, May 09, 2003 at 08:02:08PM -0700, jw schultz wrote:
> > unless it is changed to really have behave like the command-line
> > options i have my doubts of the value of the effort.
> 
> I see its primary purpose as being a little different than the command-
> line options:  there needs to be a way for a sysadmin to setup a server
> with restrictions that the client cannot work around; a means of
> subsetting the file list to make certain files or areas inaccessible.

I agree with you.  That is really the only value i can see
to this.  If it is to be done the patterns need to have the
same semantics as the client-side patterns.  We've too much
confusion with the pattern matching as it is to have it
further complicated by special rules that only apply to
server-side patterns.

> The command-line options let the client subset the available data to
> suit their needs.  Historically, daemon mode was created to allow
> download access, so upload support has not received as much attention
> and it is currently a second-class citizen in many ways.  Yes, this
> needs to be fixed.
> 
> > Having the behaviour of directory entries differ as this patch does
> > seems awkward.
> 
> Yeah, it's a result of the potential disconnect in how the {ex,in}clude
> lines are specified (they're always relative to the root of the module)
> and how the user requests files (the recursion can start in any subdir).
> This means that certain restrictions that affect a recursion from the
> top have no effect if the recursion starts from lower down.  I can see
> two potential ways to make this work as the user would expect.  One is
> to auto-add a "dir/**" rule when the user specifies a "dir/" rule.
> Another, probably better solution, is to run all the dirs in the
> command-line args through the {ex,in}clude rules (one dir at a time,
> deeper and deeper), and if the starting dir is excluded, discard that
> command-line arg.  I'll look into changing this.

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.

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".

It looks like we need to test the pattern as a substring of
location and the location as a substring of the pattern.
Then if the location is a substring of the pattern either
strip off the common prefix to add the pattern to the
exclude list or make comparisons where flist entries are
fleshed out to the module root for left-anchored patterns.

> > Better is for the server to apply this exclude list independently from
> > the client supplied one such that exclusion in either list will apply.
> 
> This is what happens on downloads already.

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.  This means a
server-side -* would override any client-side patterns
significantly limiting the effectiveness of server-side
patterns.

For this to be fully supportable an admin should be able to
test a pattern set from the client command-line and then just
drop it into the config and not have it be interfered with
by additional client-side patterns.

In other words server-side could have
	+ /a/
	+ /a/b/
	- /a/*
	- /*
and client-side
	+ /a/
	+ /a/b/
	+ /a/b/c
	- */

> 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.

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

		Remember Cernan and Schmitt