[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Should authz return errors? (Was: Re: SoC: Path-based authz for Svnserve)

From: <kfogel_at_collab.net>
Date: 2005-07-01 16:36:28 CEST

David Anderson <david.anderson@calixo.net> writes:
> I'm working on the moving and adapting of the authz code to
> libsvn_repos, and during that, a question came up.
> The current code in mod_authz_svn doesn't use any error handling. In
> some cases the code runs into a malformed authz file, and when that
> happens, authz silently ignores what piece is problematic and ploughs
> on. AFAICT, there are two such cases:
> - Discovering groups with cyclic dependancies (group A contains group B
> contains group A); The second group will have the cycling dependancy
> silently ignored.
> - An ACL line for an undefined group; The undefined group is considered
> empty.
> While I can potentially understand why the second case is okay, the
> first seems like silently ignoring something which might bring a good
> deal of confusion to users who accidentally create a cyclic dependancy
> ("Why isn't user foo authorized? He's in group A, which group B
> includes...").
> So, this all comes down to: should the authz API return errors when it
> discovers a malformed ACL configuration? I'm undecided on this, because
> it changes the current behaviour (a working authz file might fail under
> the new code), and because returning svn_error_t's everywhere does
> contribute to making the interface more cumbersome.
> Thoughts?

Well, unless there's some larger issue here I'm missing, this just
sounds like a bug. Both circumstances should be detected, and return
errors -- and, I mean, returning 'svn_error_t *' is the norm in our
interfaces, so can it really be that much more cumbersome?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 1 17:38:02 2005

This is an archived mail posted to the Subversion Dev mailing list.